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FOREWORD 


This  Department  of  the  Navy  (DON)  Acquisition  and  Capabilities 
Guidebook  can  be  accessed  through  the  following  websites:  the 
Department  of  the  Navy  Issuances  Web  site 

https : // doni . daps .dla.mil/  under  "Manuals, "  the  DON  Research, 
Development  and  Acquisition  Web  site 

https : // acquisition . navy.mil/  under  "Policy  and  Guidance"  and  the 
Defense  Acquisition  Portal  (DAP)  website 

https : // dap . dau .mil /pages/ default . aspx  under  "Policies  -  DAP, " 
under  "Filter  by  Organizations, "  under  "Navy/Marine  Corps 
Common,"  scroll  down  to  "SECNAV  M-5000. 2  DON  Acquisition  and 
Capabilities  Guidebook." 

This  Guidebook  is  structured  after  the  chapter/paragraph 
numbering  sequence  of  SECNAVINST  5000. 2E.  Major  paragraph  titles 
or  headings  from  SECNAVINST  5000. 2E  are  cited  in  this  Guidebook 
for  continuity  and  even  for  cases  where  no  additional 
discretionary  guidance  is  provided.  The  chapters  in  this 
Guidebook  include  paragraphs  for  discretionary  guidance  other 
than  those  paragraphs  included  from  SECNAVINST  5000. 2E  that  are 
mandatory  policy. 

This  Guidebook  is  intended  to  be  used  as  a  companion  document  to 
SECNAVINST  5000. 2E.  It  contains  citations  from  SECNAVINST 
5000. 2E  and  other  mandatory  references  for  process  clarification. 

While  the  Guidebook  does  not  introduce  new  or  additional 
mandatory  policy,  the  dynamic  nature  of  the  Capabilities 
Development  Process  demands  continuous  communication  among  all 
participants.  As  the  Capabilities  Development  and  Acquisition 
Management  Processes  mature,  policy  changes  may  affect 
acquisition  strategies  and  timelines.  Timely  assessment  of  the 
change,  coupled  with  the  appropriate  acquisition  strategy 
adjustment,  may  be  vital  to  the  preservation  of  an  acquisition 
timeline.  This  Guidebook  references  DoDI  5000.02  of  8  Dec  2008 
and  some  of  its  paragraphs.  The  acquisition  decision  points  and 
phase  names  of  this  Guidebook  have  been  updated  per  DoDI  5000.02 
of  8  Dec  2008. 
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Enclosure  (1)  is  the  Department  of  the  Navy  Acquisition  and 
Capabilities  Guidance  for  Operation  of  the  Defense  Acquisition 
System  and  the  Joint  Capabilities  Integration  and  Development 
System.  Chapters  1  through  8  in  this  Guidebook  correspond  to 
chapters  1  through  8  in  SECNAVINST  5000. 2E.  Selected  paragraphs 
from  SECNAVINST  5000. 2E  shown  in  brackets  [in  bold  italics ]  are 
mandatory  policy.  Other  paragraphs  provide  discretionary 
guidance  as  indicated  by  the  verbs  "should"  or  "may."  Paragraphs 
from  chapters  2  and  4  of  SECNAVINST  5000. 2E  are  included  in  this 
Guidebook  for  more  complete  coverage  of  acquisition  strategy  and 
test  and  evaluation,  respectively.  Future  releases  of  the 
Guidebook  may  contain  more  or  less  discretionary  guidance  as 
appropriate . 

Chapter  9  is  a  Glossary.  Chapter  10  is  an  Acronym  List. 
Additional  chapters  will  be  added  as  the  need  arises. 

Enclosure  (1)  and  chapters  of  the  Guidebook  are: 

Enel:  (1)  Department  of  the  Navy  Acquisition  and  Capabilities 

Guidance  for  Operation  of  the  Defense  Acquisition 
System  and  the  Joint  Capabilities  Integration  and 
Development  System 

Table  of  Contents 

Chapter  1  Capabilities  Development  and  Acquisition 


Chapter 

2 

Management  Processes 

Statutory,  Regulatory,  and  Contract 

Chapter 

3 

Reporting  Information  and  Milestone 
Requirements 

Information  Technology  (IT)  Considerations 

Chapter 

4 

Integrated  Test  and  Evaluation 

Chapter 

5 

Resource  Estimation 

Chapter 

6 

Systems  Engineering  and  Human  Systems 

Chapter 

7 

Integration 

Acquisition  of  Services 

Chapter 

8 

Program  Management 

Chapter 

9 

Glossary 

Chapter 

10 

List  of  Acronyms 

Elliott  B.  Branch 

Deputy  Assistant  Secretary  of  the  Navy 
(Acquisition  and  Procurement) 
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Chapter  1 

Capabilities  Development  and  Acquisition  Management  Processes 

References:  (a) 

SECNAVINST  5000. 2E 

(b) 

CJCSI  3170. 01H 

(c) 

CJCSI  6212. 01E 

(d) 

Under  Secretary  of  the  Navy  Memorandum, 

Organizational  Realignments  and  Designation  as 

the  Department  of  the  Navy  Deputy  Chief 

Information  Officer  (Navy)  and  the  Department  of 

the  Navy  Deputy  Chief  Information  Officer 

(Marine  Corps) ,  of  11  May  2011 

(e) 

Title  44,  U.S.  Code  (USC) ,  Section  3506 

(f) 

Title  10,  U.S.  Code  (USC),  Section  5013 

(g) 

Department  of  the  Navy  Deputy  Chief  Information 

Officer  (Navy)  Memorandum,  Navy  Enterprise 

Architecture  and  Data  Strategy  (NEADS)  Policy,  6 

(h) 

Apr  2007 

NAVADMIN  236/04;  Subj :  IM-IT  Enterprise 

Governance 

(i) 

Marine  Corps  Order  (MCO)  3900. 15B,  Marine  Corps 

Expeditionary  Force  Deployment  System,  of  10  Mar 

2008 

(j) 

OPNAVINST  5420. 108D 

(k) 

Manual  for  the  Operation  of  the  Joint 

Capabilities  Integration  and  Development  System, 

of  19  Jan  2012 

(1) 

Department  of  the  Navy  Information  Management 

and  Information  Technology  Strategic  Plan,  FY 

2008  -  2009 

(m) 

Deputy  Chief  of  Naval  Operations  (N6/N7) 

Memorandum,  FORCEnet  Requirements/Capabilities 

and  Compliance  (FRCC)  Policy,  of  27  May  2005 

(n) 

SECNAVINST  3501. IB 

(o) 

DOD  Instruction  5000.02  of  8  Dec  2008 

1 . 1  Capabilities  Development  Process 


[ from  SNI  5000.2E,  1.1:  The  Department  of  the  Navy  (DON) 
uses  a  capabilities-based  approach  to  define ,  develop ,  and 
deliver  technologically  sound,  sustainable,  and  affordable 
military  capabilities.  This  approach  is  implemented  via  the 
Naval  Capabilities  Development  Process  (NCDP) ,  the  Expeditionary 
Force  Development  System  (EFDS) ,  and  the  Joint  Capabilities 
Integration  and  Development  System  (JCIDS)  to  improve  existing 
and  develop  new  warfighting  capabilities.  Coordination  among 
Department  of  Defense  (DoD)  Components  and  among  DON  is  an 
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essential  element  of  these  processes .  Joint  concepts ,  DON 
concepts ,  concepts  of  operation  (CONOPs)  ,  and  DON  enterprise 
architecture  (EA)  are  used  to  identify  and  prioritize 
capabilities  gaps  and  integrated  doctrine ,  organization , 
training,  materiel,  leadership  and  education ,  personnel,  and 
facilities  (DOTMLPF)  solutions.]  Reference  (a),  paragraph  1.1, 
and  other  applicable  references  outline  the  major  roles  and 
responsibilities  and  provide  specific  processes  for  DON 
capabilities  development. 

For  all  DON  capabilities  identified  for  development,  the 
requisite  JCIDS  analysis  required  by  reference  (b)  must  be 
completed.  A  key  component  of  this  analysis  should  be  the  use  of 
joint  operating  concepts,  joint  functional  concepts,  and 
Integrated  Architectures  to  define  capability  gaps,  capability 
need,  and  approaches  to  provide  the  capability.  Reference  (c) 
provides  guidance  on  interoperability  and  supportability  of 
information  technology  (IT)  and  national  security  systems  (NSS) 
and  establishment  of  the  net-ready  (NR)  key  performance  parameter 
(KPP) .  Additional  information  concerning  establishing  a 
meaningful,  measurable,  and  testable  NR-KPP  is  provided  in  the 
DASN (RDT&E)  CHSENG  NR-KPP  Implementation  Guidebook,  located  at 
https://nserc. navy .mil/ sere sources /Documents /ASN%20RDA%20CHSENG/N 
R-KPP  Guidebook  V2  signed30SEP2011.pdf. 

The  dynamic  nature  of  the  capabilities  development  process 
demands  continuous  communication  between  all  participants. 

Changes  in  capabilities  development  and  acquisition  management 
processes  may  potentially  impact  program  cost,  schedule,  and 
performance.  The  timely  assessment  of  any  change,  coupled  with 
an  appropriate  acquisition  strategy  adjustment,  may  be  vital  to 
the  preservation  of  an  acquisition  timeline. 

1.1.1  DON  Principal  Capabilities  Points  of  Contact 

1.1. 1.1  Chief  of  Naval  Operations  (CNO) /Commandant  of  the 
Marine  Corps  (CMC)  Responsibilities 

1.1. 1.2  Program  and  Resource  Sponsor  Responsibilities 

1.1. 1.3  Deputy  CNO  (Integration  of  Capabilities  and 
Resources)  (CNO  (N8) )  Responsibilities 

1.1. 1.4  Deputy  CNO  (Information  Dominance)  (CNO  (N2/N6) ) 
Responsibilities 

Pursuant  to  references  (d) ,  (e) ,  (f) ,  (g) ,  and  (h)  ,  the 

Deputy  Chief  of  Naval  Operations  for  Information  Dominance  (CNO 
(N2/N6) ) ,  serving  in  an  additional  capacity  as  the  Department  of 
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the  Navy  Deputy  Chief  Information  Officer  (Navy) 

(DDCIO (N) ), ensures  that  IT  and  IM  resources  are  managed  in  an 
efficient  and  effective  manner,  and  ensures  the  development, 
implementation,  and  maintenance  of  necessary  architecture 
products  and  associated  standards  that  are  consistent  with  DON, 
DoD,  and  Federal  architectures.  Reference  (g)  aligned  Navy 
programs  and  initiatives  to  a  Navy  EA  and  data  strategy  (NEADS) 
to  ensure  compliance  with  DON  and  DoD  guidance,  and  directed 
establishment  of  information  technology  management  council  (ITMC) 
as  the  primary  IT  governance  forum  to  support  DDCIO (N)  in 
executing  the  mission  and  vision  of  the  Navy. 

CNO  (N2/N6) /DDCIO (N)  primary  roles  and  responsibilities  in 
Navy  capabilities  development  include  the  following: 

Serve  as  the  Navy  chief  architect  and  the  single  Navy  lead 
for  architectures,  executing  Navy  statutory  and  regulatory 
responsibilities  and  establishing  Navy  policy  in  all  areas  of 
architectures,  associated  standards,  supporting  data,  and  related 
processes.  Make  recommendations  to  VCNO  and  CNO  and/or  to  DON 
CIO  regarding  all  Navy  resources,  efforts,  and  policies  related 
to  development,  implementation,  and  maintenance  of  necessary 
architecture  products,  ensuring  those  products  are  consistent 
with  DON,  DoD,  and  Federal  architectures. 

1.1.2  DON  Capabilities  Development  and  Processing  Procedures 

1.1. 2.1  Naval  Capabilities  Development  Process 

1.1. 2. 2  Marine  Corps  Capabilities  Development  Process  for 
Programs  with  Navy  Fiscal  Sponsorship 

For  Marine  Corps  capabilities,  use  the  EFDS  process 
outlined  in  references  (i)  to  develop  warfighting  capabilities  to 
meet  national  security  objectives.  The  system  guides  the 
identification,  development,  and  integration  of  warfighting  and 
associated  support  and  infrastructure  capabilities  for  the  MAGTF. 
EFDS  integrates  tasks  across  the  seven  pillars  of  combat 
development  and  the  six  warfighting  functions  (WFF) ,  and 
addresses  the  direct  support  provided  to  the  MAGTF  by  the 
Supporting  Establishment  (SE) ,  and  the  Department  of  the  Navy  for 
afloat  applications. 

1.1. 2. 3  Weapon  and  Information  Technology  Systems 
Capabilities  Development  and  Processing  Procedures 

1.1. 2. 3.1  Capabilities  Based  Assessment  (CBA)  and 
Initial  Capabilities  Document  (ICD) 
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The  Navy  Capabilities  Board  (NCB)  Charter  (N80)  defines 
the  process  for  CBA  Initiation  within  Navy.  The  proposing 
organizations  develops  a  CBA  initiation  brief  IAW  the  template, 
and  routes  it  to  N81  (relevant  branch  head)  for  review  and 
endorsement.  Once  N81  provides  an  assessment  of  the  proposed 
effort,  the  effort  may  proceed  to  the  NCB.  Once  the  NCB  reviews 
and  concurs  with  the  effort,  N8  may  approve  initiation  of  the 
CBA.  See  reference  (j)  for  CNO  executive  decision-making 
process . 


The  CBA  should  not  seek  to  solve  the  gaps.  Pursuant  to 
reference  (k) ,  CBAs  emphasize  problem  identification  and 
assessment  of  risk,  because  the  fundamental  decision  is  whether 
DoD  should  take  action  to  mitigate  an  unacceptable  gap/risk.  The 
CBA  must  also  consider  possible  solutions  to  guide  further 
action.  Those  actions  include  development  of  a  DOTMLPF-Policy 
(DOTMLPF-P)  Change  Recommendation  (DCR) ,  an  Initial  Capabilities 
Document  (ICD),  or  maybe  both.  The  ICD  is  a  document  summarizing 
the  CBA  process  results.  Sponsors  develop  the  ICD  when  the  CBA 
identifies  a  need  for  materiel  solutions  to  fill  the  capability 
gaps  (i.e.,  identifies  the  need  for  an  acquisition  program) .  A 
DCR  documents  capability  gaps  that  can  be  filled  by  non-materiel 
solutions,  defines  those  solutions,  identifies  actions,  office  of 
primary  responsibilities  (OPRs) ,  costs,  and  schedules  to 
complete.  Development  of  the  DCR  may  immediately  follow  the  CBA 
(when  an  ICD  is  not  needed),  or  may  follow  approval  of  the  ICD. 

Completion  of  the  CBA  is  followed  by  a  brief  of  the  CBA 
results  to  the  NCB.  This  brief  (or  any  NCB  brief)  can  instead  be 
reviewed  by  the  N8-chaired  Resources  and  Requirements  Review 
Board  (R3B)  if  desired  by  the  R3B  chairman  or  an  R3B  member, 
based  upon  the  potential  for  political,  budgetary,  or  technical 
issues  requiring  discussion.  The  CBA  results  must  be  uploaded  to 
the  Knowledge  Management/Decision  System  (KMDS)  studies 
repository  upon  approval  by  the  appropriate  authorities. 

The  CBA  Summary  brief  captures  the  results  of  the  CBA 
process  and  recommends  further  actions.  The  brief  is  usually 
referred  to  as  an  ICD  Initiation  brief;  however,  ICDs  are  not 
always  the  most  prudent  action  following  a  CBA.  The  CBA  Summary 
brief  identifies  the  major  outputs  of  a  CBA,  as  stated  by 
reference  (k) : 

a.  A  description  of  the  mission  and  military  problem 
being  assessed; 

b.  Identification  of  the  tasks  to  be  completed  to  meet 
the  mission  objectives; 

c.  Identification  of  the  capabilities  required; 
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d.  An  assessment  of  how  well  the  current  or  programmed 
force  meets  the  capability  needs; 

e.  An  assessment  of  operational  risks  where  capability 
gaps  exist; 

f.  Recommendations  for  possible  non-materiel  solutions  to 
the  capability  gaps;  and 

g.  Recommendations  for  potential  materiel  approaches  (if 
required) . 

Once  the  program  sponsor  writes  an  ICD  summarizing  the 
results  of  the  CBA  and  addressing  the  seven  areas  described 
above,  the  program  sponsor  will  submit  the  ICD  to  CNO  (N83)  for  a 
period  of  Flag-level  review  by  the  OPNAV  staff  and  Fleet  before 
proceeding  to  a  Navy  board  (NCB  or  R3B) .  If  the  anticipated 
result  of  that  ICD  is  either  an  ACAT  I  program  or  shipbuilding 
effort,  that  board  will  be  a  Gate  1  review.  Table  E1T3  of 
reference  (a)  contains  Gate  entrance  criteria.  Gate  1  will 
determine  if  Navy  (at  the  3-star  level)  endorses  the  ICD, 
endorses  the  AoA  guidance,  and  approves  the  ICD  to  enter  Joint 
staffing.  Gate  1  also  includes  a  review  of  program  health 
(Probability  of  Program  Success  [PoPS]  criteria) ,  and  grants 
permission  to  continue  to  an  MDD  conditional  upon  ICD  approval. 
Most  Navy  ICDs  reviewed  at  Gate  1  will  require  subsequent 
approval  by  both  the  CNO  and  JROC .  See  paragraph  1.1. 2. 3. 4. 2, 
subparagraphs  c.,  d.,  and  e.  for  JCIDS  document  validation  and 
approval  authorities. 

Once  a  Navy  ICD  is  endorsed  by  the  relevant  Navy  board,  it 
will  be  submitted  by  the  program  sponsor  to  CNO  (N83)  for  Joint 
staffing . 


1.1. 2. 3. 2  Capability  Development/Production  Documents 

(CDDs/CPDs) 

A  CDD  captures  the  proposed  program  information 
necessary  to  develop  one  or  multiple  affordable  increment (s)  of 
capability  that  is  useful,  supportable,  and  that  can  be 
effectively  developed,  produced  or  acquired,  deployed  and 
sustained.  The  CDD  is  the  sponsor's  primary  means  of  defining 
authoritative,  measurable  and  testable  capabilities  needed  by  the 
warfighters  to  support  the  engineering  and  manufacturing 
development  (EMD)  phase  of  an  acquisition  program.  By 
referencing  the  originating  ICD  and  other  overarching  DOTMLPF-P 
changes  necessary  to  meld  the  family  of  systems  (FoS)  and  system 
of  systems  (SoS)  into  an  effective  capability,  the  CDD  outlines 
the  overall  strategy  to  develop  the  full  or  complete  capability. 
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Depending  upon  the  ACAT  level  of  the  future  program,  the  program 
sponsor  must  ensure  a  CDD  is  validated  and  approved  before  each 
Pre-EMD  Review  or  milestone  B  decision.  For  programs  subject  to 
the  Gate  Review  process  pursuant  to  reference  (a) ,  an  initial 
Service-approved  CDD  and  developmental  system  CONOPS  are  required 
to  support  a  Gate  3  review  decision  before  a  milestone  A 
decision.  For  non-Gate  Review  programs,  a  draft  Service  CDD  and 
CONOPS  are  required  by  reference  (k)  before  milestone  A,  to 
inform  the  TDS  and  Request  for  Proposals  (RFP)  for  the  Technology 
Development  Phase  following  the  milestone  A  decision. 

An  analysis  of  alternatives  (AoA)  normally  leads  the 
development  of  the  CDD.  The  AoA  and  CDD  may  be  developed  and 
updated  in  parallel.  However,  since  the  final  CDD  should  be 
consistent  with  the  AoA,  the  AoA  results  should  be  available  for 
inclusion  in  the  CDD  to  allow  for  CDD  independent  validation 
efforts.  Thus,  the  minimum  acceptable  operational  requirements 
(i.e.,  thresholds)  and  objectives  in  the  CDD  will  be  consistent 
with  the  AoA  results  for  program  initiation.  If  an  AoA  has  not 
been  conducted,  the  program  sponsor  and  PEO/SYSCOM 

Commander /DRPM,  will  submit  a  waiver  request  to  the  DON  AoA  Study 
Plan  approval  authorities  (CNO  (N81)  or  DC,  CD&I  and  ASN (RD&A) ) 
with  an  explanation  and  an  electronic  copy  of  whatever 
alternative  analysis  has  been  performed  (or  is  planned) .  In 
either  case,  the  AoA  results,  or  other  acceptable  analysis,  must 
be  uploaded  to  the  KMDS  studies  repository  by  the  appropriate 
authorities . 

The  CPD  captures  the  production  attributes  and  quantities 
specific  to  a  single  increment  of  an  acquisition  program,  and  is 
issued  when  the  projected  capabilities  of  that  increment  have 
been  identified  during  the  EMD  phase  with  sufficient  accuracy  to 
begin  production.  The  program  sponsor  must  ensure  a  CPD  is 
validated  and  approved  before  each  milestone  C  decision. 

Reference  (b)  allows  for  revalidation  of  a  CDD  as  a  CPD  for  use 
at  milestone  C  in  those  cases  where  the  CDD  adequately  describes 
the  system  to  be  produced,  few  changes  to  the  document  are 
required  and  all  KPP  threshold  values  are  being  met.  When 
seeking  revalidation  of  a  CDD  as  a  CPD,  architectures  of  the 
document  must  meet  the  standards  expected  of  a  CPD  (per 
references  (b) ,  (c) ,  and  (k) ) ,  and  be  re-certified  by  the  Joint 

Staff . 

Reference  (b)  also  states  that,  for  information  systems 
(IS)  that  provide  capabilities  through  software  development  and 
integration  with  commercial-off-the-shelf  (COTS)  hardware,  a  CPD 
is  not  required  unless  the  program  is  going  through  a  formal 
milestone  C  decision  and  the  MDA  requires  a  CPD.  For  programs 
taking  an  evolutionary  acquisition  approach,  or  undergoing  pre¬ 
planned  technology  insertions  of  hardware  or  software  (sometimes 
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called  rapid  capability  insertion  (RCI)  process),  a  technology 
insertion  (TI)  approach  to  JCIDS  may  be  appropriate.  The  TI 
approach  is  a  Navy-specific  implementation  of  flexibility 
described  by  the  Joint  Staff's  "IT  Box."  The  difference  in  the 
Navy's  approach  to  the  "IT  Box"  is  that  any  mature  system  (not 
just  IS)  that  is  now  engaged  primarily  in  evolution  of  its 
software  may  adopt  the  Navy' s  TI  approach  to  documenting  and 
managing  those  evolving  software  requirements.  This  includes 
programs  conducting  COTS/government-of f-the-shelf  (GOTS)  hardware 
insertions  (not  hardware  development) . 

Under  the  TI  approach,  a  program  may  describe  between  6-8 
years  of  planned  capability  evolution  in  a  single  new  CDD  (or  via 
updates  to  a  previously  approved/serialized  CDD,  CPD,  operational 
requirements  document  (ORD) ) ,  and  an  approach  for  active  OPNAV 
management  of  the  evolution  of  system  capabilities  from  threshold 
to  objective  values  over  those  6-8  years.  Rather  than  write  a 
new  CPD  for  each  evolution  of  capability,  the  Requirements 
Officer  may  draft  a  production  annex  (PA)  to  the  approved  CDD  to 
document  each  specific  planned  insertion.  As  designated  by  the 
CDD  approval  authority,  the  PA  may  be  approved  at  a  lower  level, 
but  must  be  provided  to  CNO  (N83)  for  inclusion  with  the  approved 
parent  document  in  the  joint  staff  (J-8)  KMDS .  CNO  (N83)  must 
endorse  a  program  taking  this  TI  approach  to  the  JCIDS  process. 
Implementation  of  the  approach  will  be  approved  by  the  NCB  or 
R3B.  Potential  new  IS  may  adopt  the  "IT  Box"  earlier  by 
preparing  an  IS  ICD.  Subsequent  documents  defining  system 
capabilities  will  be  a  CDD  and/or  CPD  as  appropriate  -  no  other 
documentation  suggested  by  reference  (k)  will  be  approved  by  the 
Navy  following  an  IS  ICD. 

References  (b)  and  (k)  provide  the  guidance  for  DON 
development  of  the  CDD  and  CPD.  Program  sponsors  will  consider 
time-phased  requirements  in  the  development  of  CDDs  in  order  to 
reduce  cycle  time  for  technology  insertion,  acquisition, 
deployment,  and  modernization  of  weapon  systems  and  information 
technology  systems.  References  (b)  and  (k)  also  provide  guidance 
for  Marine  Corps  program  CDD  and  CPD  development. 

1.1. 2. 3. 3  ICD/ CDD/ CPD  Formulation 

The  program  sponsors  will  accomplish  the  following  in  the 
preparation  of  DON  capability  documents: 

a.  Ensure  CBA  has  thoroughly  assessed  whether  non¬ 
materiel  alternatives  or  mitigations  exist. 

b.  For  ICD  development,  propose  ICD  initiation  at  a  NCB 

or  R3B . 
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c.  For  CDD  and  CPD  development,  verify  that  capability 
gaps  and  AoA  results  have  been  approved. 

d.  Prepare  draft  ICDs,  CDDs,  and  CPDs  per  reference  (k) , 
enclosures  F,  G,  and  H,  respectively,  appendix  A 

(content/format) .  Verify  with  CNO  (N83) ,  for  Navy,  or  HQMC  Joint 
Capabilities  Assessment  and  Integration  Division  ( JCAID) ,  for 
Marine  Corps,  whether  the  ICD/CDD/CPD  must  be  developed  using  the 
Joint  Staff' s  Capability  Development  Tracking  and  Management 
(CDTM)  software  tool.  Marine  Corps  programs  will  be  forwarded  by 
the  Commanding  General,  Marine  Corps  Combat  Development  Command 
(CG,  MCCDC) . 

e.  Coordinate  with  the  program  executive  officer  (PEO) , 
Systems  Command  (SYSCOM)  commander,  direct  reporting  program 
manager  (DRPM) ,  and  program  manager  (PM)  or  the  cognizant  Deputy 
Assistant  Secretary  of  the  Navy  (Research,  Development  and 
Acquisition)  (DASN (RD&A) )  to  verify  the  potential  acquisition 
category  (ACAT) . 

f.  Coordinate  with  CNO  (N83)  before  staffing  to  ensure 
appropriate  OPNAV  review/endorsement  boards  are  identified  (see 
annex  1-A  for  Navy  requirement,  capability  documents  flow  and 
annex  1-B  for  initial  capabilities,  capability  development, 
production  document  signature  page) .  Ensure  that  the  document 
complies  with  requirement  for  development/production  and  content 
(see  reference  (k)  and  annexes  1-C  and  1-D) . 

g.  For  CDDs  and  CPDs,  ensure  that  performance  parameters 
satisfy  the  mission  need  and  KPPs  and  key  system  attributes 
(KSAs)  are  clearly  identified. 

h.  Submit  ICDs,  CDDs,  and  CPDs  to  OPNAV  N83  for 
validation  and  approval  upon  successful  completion  of  all  reviews 
and  receipt  of  required  certifications. 

1.1. 2. 3. 4  Navy  Capabilities  Document  Flow  Process 

The  goal  of  the  JCIDS  document  flow  process  is  to 
facilitate  efficient  routing  of  capabilities  documents  while 
providing  a  high  quality  set  of  requirements.  The  OPNAV  Staff 
has  reviewed  the  joint  and  Navy  capabilities  documents  routing 
process  to  make  improvements  for  better  support  and  more  timely 
validation  and  approval  of  these  documents. 

Reference  (b)  establishes  the  JCIDS  process  and  identifies 
document  staffing  guidelines.  Reference  (a)  delineates  the  JCIDS 
document  validation  and  approval  process  within  the  Navy.  Per 
reference  (a) ,  Navy  capability  documents  are  required  to  be 
validated  and  approved  by  CNO  and  the  joint  requirements 
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oversight  council  (JROC)  for  ACAT  level  I  and  IA  programs,  VCNO 
for  ACAT  II  through  IV  JROC  interest  or  joint  capabilities  board 
(JCB)  interest  programs,  and  by  CNO  (N8)  for  ACAT  level  II  and 
below  programs  that  are  not  JROC  interest  or  JCB  interest. 
Approval  of  PAs  may  be  delegated  beyond  these  validation  and 
approval  authorities  upon  reguest,  usually  when  the  parent 
document  is  approved,  or  upon  any  subseguent  approved  adoption  of 
the  TI  approach. 

1.1. 2. 3. 4.1  Roles  and  Responsibilities 

a .  Resource  Sponsor 

Upon  receipt,  the  resource  sponsor' s  requirements  officer 
(RO)  will  expeditiously  route  the  capabilities  document  package 
through  the  sponsor's  organization  for  flag-level  endorsement, 
with  timely  updates  on  its  status  to  the  designated  CNO  (N83) 
representative . 

b.  CNO  (N83) 

The  designated  CNO  (N83)  representative  will  staff  all 
capability  documents  through  the  Navy  and  Joint  organizations  for 
review,  and  assist  in  coordinating  Navy  reviews  (naval 
capabilities  board  (NCB) ,  resources  and  requirements  review  board 
(R3B) ,  and/or  Gate  review),  and  Joint  Staff  reviews  (functional 
capabilities  boards  (FCBs) ,  JCB,  and  JROC)  as  required.  CNO 
(N83)  will  also  help  staff  Navy  capabilities  documents  through 
the  appropriate  organizations  for  signature.  CNO  (N83)  will  help 
determine  applicability  of  ICD  Waiver  requests,  and  route  request 
to  CNO  (N83)  for  endorsement  prior  to  uploading  waiver  request  on 
KMDS  pursuant  to  reference  (k)  . 

c.  CNO  (N8) 

Using  the  R3B  or  NCB,  approves  initiation,  endorses,  or 
validates  and  approves  Navy-sponsored  CBAs  and  JCIDS  documents. 
Recommends  approval  for  document  entry  into  joint  staffing  and 
endorses  the  document  for  final  VCNO  and  CNO  approval  after  joint 
comment  resolution,  as  appropriate. 

1.1. 2. 3. 4. 2  Joint  Capabilities  Integration  and 
Development  System  (JCIDS)  Document  Routing  and  Review  Process 

The  staffing,  signature,  and  final  review  process  for  Navy 
requirements/capabilities  documents  is  shown  in  annex  1-A. 

a .  Process  for  Navy  Review 
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(1)  Program  sponsor  will: 

(a)  Submit  Navy-sponsored  capabilities  documents 
to  CNO  (N83)  for  distribution  to  the  appropriate  CNO  staff  codes 
for  review.  CNO  (N83)  distribution  will  include  Commander,  Fleet 
Forces  Command  (CFFC)  for  Fleet  review,  and  per  reference  (a) , 
the  Director  Strategic  Systems  Program  (DIRSSP) . 

(b)  OPNAV  sponsor  will  forward  a  copy  of  the  draft 
capabilities  documents  to  ASN (RD&A) ,  DASN (RDT&E)  chief  systems 
engineer  (CHSENG) ,  DASN (RD&A)  (international  programs)  (IP),  and 
cognizant  DASN (RD&A)  and  PEO,  SYSCOM,  and  DRPM  for  information. 

(c)  The  notional  timeframe  for  Navy  review  is  21- 
calendar  days.  The  review  period  is  followed  by  a  45-calendar 
day  sponsor  comment  adjudication  period. 

(d)  Communication  with  CNO  (N83)  early  and 
frequently  during  the  staffing  process  is  key  to  successful  and 
timely  staffing  of  these  capabilities  documents.  Notionally,  the 
staffing,  signature,  and  review  processes  take  about  9  months  for 
JROC  Interest  documents.  CNO  (N83)  will: 


documents . 


1  Conduct  an  initial  review  of  capabilities 


2  Receive  comments  from  the  Navy  Staff  and 
CFFC  and  provide  these  comments  to  the  sponsor. 

(2)  Naval  capabilities  board  (NCB) ,  resources  and 
requirements  review  board  (R3B) ,  and  gate  process 

(a)  The  NCB  and  R3B,  as  part  of  the  gate  process 
when  required,  will  review  and  validate  all  Navy-sponsored  JCIDS 
documents.  Prior  to  this  review,  the  FORCEnet  requirements  must 
be  certified  by  CNO  (N2/N6) . 

(b)  Signature  by  CNO  (N8)  will  suffice  for  all  3- 
star  endorsements  of  Navy-sponsored  JCIDS  documents. 

b.  Process  for  Joint  Review 


(1)  CNO  (N83)  will: 

(a)  Verify  final  document  compliance  and  that  all 
endorsements  (FORCEnet,  NCB,  R3B,  and  gate)  are  received. 

(b)  Forward  JCIDS  documents  to  the  Joint  Staff  (J- 
8)  for  review  and  receipt  of  Joint  certifications,  as  required. 
Reference  (b)  covers  the  JCIDS  joint  staffing  process. 
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c .  Final  Navy  Approval 

(1)  After  sponsor  resolution  of  comments,  the  document 
will  be  reviewed  by  the  NCB  and/or  R3B,  as  necessary,  to  review 
any  changes  that  might  modify  Navy  equities  in  the  document  or 
are  contrary  to  Navy  leadership  direction/decisions  regarding 
that  document . 

(2)  CNO  (N8)  endorses  applicable  Marine  Corps  program 
ICD,  CDD,  and  CPDs  (Assistant  Commandant  of  the  Marine  Corps 
(ACMC)  approves) .  At  the  R3B  Executive  Secretary's  discretion, 
the  document  may  bypass  the  R3B  and  go  straight  to  CNO  (N8)  for 
endorsement.  CNO  (N83)  will  forward  endorsed  ICD,  CDD,  and  CPD 
to  CMC  (Deputy  Commandant  of  the  Marine  Corps  (Combat  Development 
and  Integration  (DC,  CD&I) ) )  for  ACMC  review  and  approval  for 
applicable  Marine  Corps  programs. 

(3)  The  NCB  and/or  R3B  shall  endorse  all  Navy 
capabilities  documents  for  Navy  approval  by  appropriate 
authority.  CNO  (N8)  approves  all  ACAT  II  or  lower  capabilities 
documents  designated  Joint  Integration,  Joint  Information,  or 
Independent.  Vice  Chief  of  Naval  Operations  (VCNO)  approves  all 
capabilities  documents  designated  JCB  Interest,  prior  to  review 
by  the  JCB.  CNO  approves  all  ACAT  I  capabilities  documents,  and 
those  designated  JROC  Interest,  prior  to  review  by  the  JROC . 
Documents  are  forwarded  to  United  States  Fleet  Forces  (USFF)  Code 
N00  for  endorsing  signature  prior  to  VCNO  signature.  Most 
changes  to  approved  capabilities  documents'  KPPs  and  KSAs  are 
approved  in  the  same  manner. 

d.  Joint  Staff  Validation  Approval 

At  the  conclusion  of  the  joint  comment  resolution  period, 
CNO  (N83)  will  post  the  document  in  the  joint  staff 
(J-8)  KMDS  for  certification,  when  required.  Navy  4-star 
signatures  are  required  prior  to  JCB  and  JROC  review,  validation, 
and  approval  (JCB  interest  and  JROC  interest  documents  only) . 
Reference  (b)  applies  for  joint  staffing  of  JCIDS  documents. 

e.  JROC  Interest  and  JCB  Interest  Endorsement 


(1)  NCB  and/or  R3B  will  review  and  endorse  all  ICD, 
CDD,  and  CPD  (Navy  and  applicable  Marine  Corps  programs)  for 
approval . 

(2)  VCNO  will: 

(a)  Review  and  provide  Navy  approval  of  Navy  JCB 
interest  ICD,  CDD,  and  CPDs,  prior  to  the  JCB  review.  VCNO  will 
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review  applicable  Marine  Corps  programs. 

(b)  Review,  endorse,  and  forward  ACAT  I  and  JROC 
interest  ICD,  CDD,  and  CPDs  to  CNO,  prior  to  the  JCB  review. 

(c)  Review  and  comment  as  needed  on  proposed  JROC 
briefing  (Navy  programs  only)  . 

(3)  CNO  will: 

(a)  Review  and  provide  Navy  approval  of  Navy  ACAT 
I  and  JROC  interest  ICD,  CDD,  and  CPDs  prior  to  the  JROC. 

(b)  Review  applicable  Marine  Corps  programs  prior 

to  the  JROC . 

f .  JROC  Validation  and  Approval  of  ACAT  I  and  IA  and  JROC 
Interest  Programs 

(1)  CNO  (N83)  will: 

(a)  For  Navy-sponsored  documents,  coordinate  with 
program  sponsor  to  provide  JROC  briefings  (FCB,  JCB,  and  JROC) 
following  the  Navy  process  and  monitor  progress  of  JROC  interest 
ICD,  CDD,  and  CPD  validation  and  approval. 

(b)  For  applicable  Marine  Corps  programs,  forward 
N8  endorsement  to  CMC  (DC,  CD&I),  as  applicable. 

g.  Issuance 

(1)  CNO  (N83)  will: 

(a)  Serialize  ICD,  CDD,  and  CPD  (###-[ Sponsor  N- 
code]-CY)  and  post  the  document  to  the  Joint  Staff  J-8  KMDS . 

(b)  Retain  the  document  for  configuration 
management/archive  purposes. 

(2)  The  program  sponsor  will: 

(a)  Forward  the  ICD,  CDD,  and  CPD  to  ASN (RD&A)  for 
potential  ACAT  I  and  IA  or  potential  ACAT  II  designation,  or  PEO, 
SYSCOM,  and  DRPM  for  potential  ACAT  III  or  IV  designation,  and 
initial  milestone  scheduling. 

(3)  ASN (RD&A)  will: 

(a)  Forward  potential  ACAT  I  and  IA  ICDs  to 
USD(AT&L)  and  DoD  CIO  for  designation  and  initial  milestone 
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scheduling . 


(b)  Forward  the  approved  CDD  and  CPD  to  the 
milestone  decision  authority  (MDA)  and  PM. 

(4)  MDA  will: 

Schedule  a  milestone  meeting. 

1.1. 2. 3. 5  Navy  Capabilities  Document  Change  Process 

Over  time,  changes  to  capabilities  documents  may  be 
reguired.  Reasons  for  document  changes  may  range  from  revised 
KPP  criteria  to  small  administrative  changes. 

Realizing  that  some  capabilities  document  changes  may  be 
less  critical  than  others,  the  change  process  is  based  on  the 
type  of  change  and  the  category  of  the  document  and  has  different 
document  staffing  and  approval  requirements.  The  staffing  and 
approval  levels  of  capabilities  document  changes  may  differ  based 
on  the  joint  potential  designator  (JPD)  of  the  capabilities 
document.  (See  reference  (b)  for  description  of  JPDs) .  The 
document  change  criteria  include  three  categories  as  follows. 

1.1. 2. 3. 5.1  Changes  to  Key  Performance  Parameter 
(KPP)  Requirements 

KPP  changes  may  result  from  (1)  schedule  changes  to 
delivering  the  capability,  (2)  requirements  changes  as  a  program 
matures,  (3)  de-scoping  of  requirements,  and  (4)  CDD,  CPD,  and 
ORD  clarifications. 

a.  For  capabilities  documents  with  a  JPD  of  JROC  interest 
or  JCB  interest,  KPP  changes  must  be  staffed  through  all  Navy 
codes,  and  other  service  codes  as  determined  by  the  joint  staff. 

Approval  authority  for  these  KPP  changes  is  either  the  JROC  or 
the  JCB,  respectively. 

b.  For  capabilities  documents  with  a  JPD  of  Joint 
Integration,  KPP  changes  must  be  staffed  through  all  Navy  codes. 
Staffing  through  KMDS  may  be  needed  if  re-certification  is 
required  due  to  proposed  changes.  Approval  authority  for  these 
changes  is  CNO  (N8),  unless  it  is  an  ACAT  I  program,  in  which 
case  CNO  has  approval  authority. 

c.  For  capabilities  documents  with  a  JPD  of  "joint 
information"  changes  must  be  staffed  through  all  Navy  codes. 
Approval  authority  for  these  changes  is  CNO  (N8) . 

d.  For  capabilities  documents  with  a  JPD  of  "independent" 
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changes  must  be  staffed  through  all  Navy  codes.  Approval 
authority  for  these  changes  is  CNO  (N8) . 

1.1. 2. 3. 5. 2  Changes  to  Non-Key  Performance 
Parameters  (Non-KPPs) 


Non-KPP  changes  may  result  from  the  same  four  causes  for 
KPP  changes:  (1)  schedule  changes  to  delivering  the  capability, 

(2)  requirements  changes  as  the  program  matures,  (3)  de-scoping 
of  requirements,  and  (4)  CDD,  CPD,  and  ORD  clarifications. 

a.  For  capabilities  documents  with  a  JPD  of  JROC  interest 
or  JCB  interest,  changes  must  be  staffed  through  all  Navy  codes. 
Approval  authority  for  these  changes  is  the  CNO  or  VCNO, 
respectively . 

b.  For  capabilities  documents  with  a  JPD  of  joint 
integration,  joint  information,  or  independent,  changes  must  be 
staffed  through  all  Navy  codes.  Approval  authority  for  these 
changes  is  CNO  (N8) . 

1.1. 2. 3. 5. 3  Administrative  Changes 

Administrative  changes  may  only  result  from  CDD,  CPD,  and 
ORD  clarifications.  Approval  authority  for  these  changes  is  CNO 
(N83)  . 


1.1. 2. 3. 5. 4  Staffing  and  Approval  Matrix  for 
Changes  to  Capability  Documents 

Table  E1T1  matrix  below  provides  an  illustration  of 
staffing  and  approval  requirements  for  changes  to  capabilities 
documents . 
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Table  E1T1  Staffing  and  Approval  of  Changes  to  Capabilities  Documents 

Joint  Potential 
Designator 

Change  Type 

Staffing 

Approval 

JROC  Interest/JCB  Interest 

KPP 

Schedule  change  for  delivering  capability 

Navy  Staffing, 
Navy  Board, 

Joint  Staffing 

JROC/JCB 

Requirements  change  as  program  matures 

Descoping  requirement 

CDD,  CPD,  and  ORD  clarification 

Non-KPP  Rqmts 
(to  include  KSA 
changes) 

Schedule  change  for  delivering  capability 

Navy  Staffing,  Navy 
Board 

CNO/VCNO 

Requirements  change  as  program  natures 

Descoping  requirement 

CDD,  CPD,  and  ORD  Clarification 

Admin 

Administrative  change  only 

N83 

N83 

Joint  Integration 

KPP 

Schedule  change  for  delivering  capability 

Navy  Staffing, 
Navy  Board 

N8 

Requirements  change  as  program  matures 

Descoping  requirement 

CDD/CPD/ORD  clarification 

Non-KPP  Rqmts 
(including  KSA 
changes) 

Schedule  change  for  delivering  capability 

Navy  Staffing,  Navy 
Board 

N8 

Requirements  change  as  program  matures 

Descoping  requirement 

CDD/CPD/ORD  clarification 

Admin 

Administrative  change  only 

N83 

N83 

Joint  Information  and  Independent 

KPP 

Schedule  change  for  delivering  capability 

Navy  Staffing,  Navy 
Board 

N8 

Requirements  change  as  program  matures 

Descoping  requirement 

CDD/CPD/ORD  clarification 

Non-KPP  Rqmts 
(including  KSA 
changes) 

Schedule  change  for  delivering  capability 

Navy  Staffing,  Navy 
Board 

N8 

Requirements  change  as  program  matures 

Descoping  requirement 

CDD/CPD/ORD  clarification 

Admin 

Administrative  change  only 

N83 

N83 
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1.1. 2. 4  Navy  Modernization  Plan 

Submitters  of  Navy  Modernization  Plan  (NMP)  Ship  Change 
Documents  (SCDs)  should  use  the  operational 
requirements/capabilities  language  from  JCIDS  documents. 
Submitters  of  a  SCD  for  ship  modernization  should  coordinate  with 
Program  Managers  (PMs)  to  ensure  that  the  cost  data  reported  in 
the  Cost  Benefit  Analysis  form  of  the  SCD  originates  from  the 
program's  independent  cost  analysis.  The  CBA  data  should  be 
consistently  reflected  in  the  associated  APB. 

1.1. 2. 5  DON  Enterprise  Architecture  (which  includes 
FORCEnet) 


The  Navy  FORCEnet  Requirements/Capabilities  and  Compliance 
(FRCC)  Flag  Board  and  Marine  Corps  Command,  Control, 
Communications,  Computers,  and  Intelligence  (C4I)  Integration 
Board  provide  guidance  for  IT  systems,  including  NSS,  FORCEnet 
requirements  and  capabilities  compliance.  For  information 
related  to  the  current  FORCEnet  Consolidated  Compliance  Checklist 
(FCCC) ,  contact  FORCEnet  representatives  in  CNO  (N2/N6) . 

Compliance  of  individual  IT  systems,  including  NSS,  with 
joint  interoperability  guidance  is  critical  for  DON 
transformation  to  a  Net-Centric  environment;  this  is  a  primary 
focus  of  FORCEnet. 

CNO  program  and  resource  sponsors  are  responsible  for 
identifying  and  defining  FORCEnet  requirements/capabilities,  and 
for  ensuring  FORCEnet  compliance  via  synthesis  of  FRCC 
requirements/capabilities  into  Navy  JCIDS  capabilities  documents 
during  development  and  review  of  these  documents,  and  into 
programming  decisions  made  during  the  NCDP. 

The  Commander,  Naval  Network  Warfare  Command  (NETWARCOM) 
and  the  CG,  MCCDC  in  support  of  their  respective  Navy  and  Marine 
Corps  program  and  resource  sponsors  are  developing  enterprise¬ 
wide  FORCEnet  integrated  architecture  operational  views  (OVs) 
during  the  development  of  IT,  including  NSS,  JCIDS  capabilities 
documents.  NETWARCOM  supports  program  and  resource  sponsors 
during  the  NCDP  process  using  the  FORCEnet  Enterprise  Team  (FET) . 

Space  and  Naval  Warfare  Systems  Command  (COMSPAWARSYSCOM) 
(FORCEnet  Chief  Engineer  (CHENG) )  leads  the  development  of 
enterprise-wide  FORCEnet  integrated  architecture  System  Views 
(SVs)  and  Technical  Views  (TVs)  for  support  of  program  and 
resource  sponsors'  preparation  of  IT,  including  NSS,  JCIDS 
capabilities  documents  per  reference  (c) .  COMSPAWARSYSCOM 
(FORCEnet  CHENG)  supports  program  and  resource  sponsors  during 
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the  NCDP  process  and  PMs  during  the  acquisition  process. 

Approved  enterprise  reference  architecture  (ERA) -based  integrated 
architectures  are  available  on  the  Naval  Architecture  Repository 
System  (NARS)  Web  site  at  https : //nars . nswc . navy.mil/ . 

Reference  (1)  defined  FORCEnet  as  an  integral  part  of  IT 
and  IM,  and  as  the  DON' s  initiative  to  achieve  Joint 
Transformation.  Reference  (m)  codified  and  promulgated  FORCEnet 
requirements,  and  established  an  initial  end-to-end  compliance 
process  for  implementation. 

1.1. 2. 5.1  FORCEnet  Requirements/Capabilities  and 
Compliance  Process 

Figure  1-1  illustrates  the  FRCC  process.  The  FRCC  is 
composed  of  the  following  steps: 

a.  Collection  of  pertinent  top-level  FRCC  guidance. 

b.  Review  of  top-level  FRCC  guidance  and  identification 
of  issues  by  a  CNO  (N2/N6F) -chaired  FRCC  Review  Board  consisting 
of  senior/O-6  level  representatives  from  OPNAV,  Naval  NETWARCOM, 
DASN (RDT&E)  CHSENG,  DON  CIO,  COMSPAWARSYSCOM  (FORCEnet  CHENG), 
and  other  organizations  invited  by  CNO  (N2/N6F) .  A  senior 
representative  from  the  Marine  Corps  will  also  participate  as  a 
liaison  to  the  FRCC  Review  Board  to  ensure  alignment  of  FORCEnet 
policy  and  implementation  across  both  Services. 

c.  Resolution  of  FORCEnet  issues  by  a  FRCC  Flag  Review 
Board,  chaired  by  CNO  (N2/N6F)  and  consisting  of  Flag/SES-level 
FORCEnet  stakeholders  as  invited  by  CNO  (N2/N6F) . 

d.  Approval  of  FRCC  Flag  Board  recommended  FORCEnet 
updates  by  CNO  (N2/N6)  (FORCEnet  sponsor) . 
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FORCEnet  Requirements/Capabilities 
and  Compliance  (FRCC)  Process 
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Figure  1-1  (see  acronyms  in  chapter  10) 

FORCEnet  Requirements/Capabilities  and  Compliance  Process 
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FORCEnet  Compliance  Support 
to  NCDP  Analysis 
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Figure  1-2  (see  acronyms  in  chapter  10) 

FORCEnet  Compliance  Support  to  Naval  Capabilities  Development 

Process  (NCDP)  Analysis 


1.1. 2. 5. 2  Support  to  Naval  Capabilities  Development 

Process 

a.  The  NCDP  was  developed  to  transform  a  threat-based, 
platform-centric  requirements  process  into  a  capabilities-based 
assessment  measured  against  "what  it  takes  to  win."  The  NCDP 
uses  FORCEnet  capabilities  to  assess  program  necessity, 
requirements,  gaps,  and  overlaps,  and  provides  a  fiscal  AoA  for 
achieving  FORCEnet  capabilities  utilizing  modeling  and 
simulation,  experimentation,  science  and  technology,  wargames, 
and  lessons  learned.  The  NCDP  addresses  the  material  component 
of  FORCEnet  capability. 


1-19 


Enclosure  (1) 


SECNAV  M-5000 . 2 
May  2012 


b.  The  FRCC  Process  shown  in  figure  1-1  supports  the 
NCDP,  enhancing  resource  decisions  by  adding  information  on  joint 
interoperability,  GIG  transition,  and  other  key  elements  to  the 
current  tradeoff  of  warfighting  capability  and  cost.  This 
support  is  described  in  figure  1-2  and  as  follows: 

(1)  The  FRCC  process  provides  validated  FORCEnet 
compliance  criteria. 

(2)  The  COMSPAWARSYSCOM  (FORCEnet  CHENG) -led  FORCEnet 
Implementation  Baseline  (FIBL) /FORCEnet  Implementation  Tool  Suite 
(FITS)  process  will  be  used  to  assess  individual  DON  acquisition 
programs  FORCEnet  compliance.  FIBL/FITS  findings  will  also  be 
used  by  COMSPAWARSYSCOM  (FORCEnet  CHENG)  in  development  of  the 
SYSCOM  FORCEnet  Assessment  input  to  NCDP. 

(3)  The  results  of  the  FIBL/FITS  assessment  will 
undergo  operational  review  by  the  Fleet  (NETWARCOM) -chaired 
FORCEnet  Enterprise  Team  (FET) .  Recommendations  from  this  review 
will  be  provided  to  appropriate  OPNAV  program  and  resource 
sponsors,  identifying  non-compliant  systems  for  potential 
consolidation  or  termination  in  the  Integrated  Sponsor' s  Program 
Proposal . 


1.1. 2. 5. 3  FORCEnet  Consolidated  Compliance  Checklist 

[ from  SNI  5000. 2E,  1.1. 2. 3  (tenth  subparagraph ,  third 
sentence  and  subsequent ,  extract) :  Program  and  resource  sponsors 
shall  use  the  current  FORCEnet  Consolidated  Compliance  Checklist 
(FCCC)  to  determine  the  applicable  NR  KPP  requirements  for  both 
tactical  (warfighting)  and  non-tactical  (business/support)  IT 
systems,  including  NSS .  The  FCCC  shall  be  validated,  maintained 
and  updated  by  Deputy  CNO  (Information  Dominance)  (CNO  (N2/N6) ) , 
and  is  available  in  the  CNO  (N6/N7)  FORCEnet  Compliance  Policy 
memorandum  of  27  May  2005.  CNO  (N2/N6)  shall  assist  program  and 
resource  sponsors  by  reviewing  all  Navy  JCIDS  documents  against 
the  current  FCCC  to  ensure  that  applicable  FORCEnet  requirements 
are  being  correctly  and  consistently  incorporated  into  these 
documents.  Commander,  Space  and  Naval  Warfare  Systems  Command 
(COMSPAWARSYSCOM)  (FORCEnet  Chief  Engineer  (CHENG) )  and  NETWARCOM 
will  use  the  current  FCCC  to  assess  individual  programs  for 
FORCEnet  compliance ,  and  shall  make  appropriate  reports  of  these 
assessments  to  Commander  Fleet  Forces  Command  (CFFC) ,  CNO 
(M2/N6)  ,  and  ASN (RD&A)  .  COMSPAWARSYSCOM  (FORCEnet  CHENG)  and 
Naval  Network  Warfare  Command  (NETWARCOM)  ,  using  the  FCCC,  shall 
assist  Program  Managers  (PMs)  in  assessing  and  achieving  FORCEnet 
compliance  for  their  programs  and  shall  report  results  of  these 
assessments  to  the  PMs  as  necessary. ] 
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a.  FORCEnet  Operational  Criteria. 

(1)  FORCEnet  Integrated  Architecture.  This  section  is 
based  on  the  FORCEnet  Integrated  Architecture  Operational  Views 
(OVs) .  The  FORCEnet  Integrated  Architecture  is  being  aligned 
with  the  GIG  Integrated  Architecture  and  will  provide  products 
which  represent  FORCEnet  requirements/capabilities  to  support 
assessment  of  capabilities  through  the  NCDP. 

(2)  FORCEnet  Capabilities  List  (FCL) .  Closely  related 
to  the  FORCEnet  Integrated  Architecture  is  the  FCL.  The  FCL  will 
map  and  time-phase  FORCEnet  capabilities  to  Joint  capabilities, 
attributes,  and  measures  in  the  Joint  Functional  Concepts  (Net- 
Centric,  Command  and  Control,  and  Battlespace  Awareness)  and 
Joint  Capability  Areas  (JCAs) ,  providing  additional  alignment  of 
FORCEnet  with  Joint  planning  and  JCIDS. 

b.  FORCEnet  System  and  Technical  Criteria.  The  FORCEnet 
System/Technical  Section  points  to  key  joint,  net-centric,  and 
GIG  technical  guideposts  and  supporting  implementation  guidance 
and  direction. 

c.  FORCEnet  Policy  Criteria.  The  FORCEnet  Policy 
Criteria  provides  a  compendium  of  guidance  in  key  FORCEnet  policy 
areas . 


d.  Implementation  Planning.  This  section  reflects 
FORCEnet  implementation  planning  by  CNO  (N2/N6)  (FORCEnet 
sponsor)  and  ASN (RD&A) . 

1.1. 2. 5. 4  FORCEnet  Compliance  Governance  Process 

FORCEnet  compliance  is  implemented  via  synthesis  of 
FORCEnet  requirements/capabilities  into  the  JCIDS  process  during 
development  and  review  of  JCIDS  documents,  as  shown  in  annex  1-A, 
and  into  the  NCDP  process,  as  shown  in  Figure  1-2.  The  FET 
process  will  be  used  to  enable  FORCEnet  compliance  in  the  Fleet 
and  Operational  Community.  Additionally,  FORCEnet  compliance 
enforcement  should  be  implemented  in  the  Fleet  Operational 
Advisory  Group  (OAG)  process.  FORCEnet  compliance  should  be 
coordinated  with  the  Sea  Trial  process. 

1.1. 2. 5. 5  Roles  and  Responsibilities 

a.  FORCEnet  Enterprise  Team  (FET)  is  led  by  NETWARCOM, 
and  consists  of  CNO  (N2/N6)  (FORCEnet  sponsor)  and  Acquisition 
Community  representatives.  The  FET  will: 
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(1)  Perform  an  operational  review  of  the  results  of 
the  FIBL/FITS  program  assessments  by  COMSPAWARSYSCOM  (FORCEnet 
CHENG)  . 


(2)  Provide  program  assessment  recommendations  to 
appropriate  OPNAV  program  and  resource  sponsors,  identifying  non- 
compliant  systems  for  potential  consolidation  or  termination  in 
the  Integrated  Sponsor's  Program  Proposal. 

b.  FORCEnet  Requirements/Capabilities  and  Compliance 
(FRCC)  Review  Board  is  chaired  by  CNO  (N2/N6F)  and  consists  of 
Senior/O-6  level  representatives  of  cognizant  OPNAV  codes,  DON 
CIO,  NETWARCOM,  DASN (RDT&E)  CHSENG,  COMSPAWARSYSCOM  (FORCEnet 
CHENG) ,  and  other  organizations  deemed  appropriate  by  CNO 
(N2/N6F) .  A  senior  representative  from  the  Marine  Corps  will 
also  participate  as  a  liaison  to  the  FRCC  Review  Board  to  ensure 
alignment  of  FORCEnet  policy  and  implementation  across  both 
Services.  The  FRCC  will: 

Consolidate  all  Top-Level  and  DON  FORCEnet  applicable 
guidance,  resolve  any  conflicting  guidance,  and  develop 
recommended  changes/updates,  which  will  be  forwarded  to  the  FRCC 
Flag  Board  for  review. 

c.  FRCC  Flag  Board  is  led  by  CNO  (N2/N6F) ,  and  consists 
of  Flag/SES  level  representatives  of  FORCEnet  stakeholders  as 
invited  by  CNO  (N2/N6F) .  The  FRCC  Flag  Board  will: 

(1)  Review  proposed  updates  to  FORCEnet  guidance  and 
resolve  any  issues  identified  by  the  FRCC  Review  Board. 

(2)  Forward  recommendations  to  CNO  (N2/N6)  (FORCEnet 
sponsor)  for  approval. 

d.  CNO  (N2/N6)  (FORCEnet  sponsor)  will: 

(1)  Make  any  necessary  adjustments  to  FRCC  Flag  Board 
recommendations  and  approve  and  promulgate  an  updates  to  FORCEnet 
guidance . 

(2)  Enforce  FORCEnet  compliance. 

e.  NETWARCOM  and  MCCDC  are  the  FORCEnet  Operational 
Agents.  Responsibilities  include: 

(1)  Co-develop  FORCEnet  Operational  Criteria. 

(2)  Develop  the  FORCEnet  Integrated  Architecture 
Operational  Views  (OVs)  in  coordination  with  the  other  FORCEnet 
stakeholders  and  OSD  staff. 
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(3)  Develop  the  FORCEnet  Capabilities  List  (FCL)  in 
coordination  with  CNO  (N2/N6)  (FORCEnet  sponsor)  and  other 
FORCEnet  stakeholders. 

f.  COMSPAWARSYSCOM  (FORCEnet  CHENG)  (lead)  with 
MARCORSYSCOM  are  the  FORCEnet  System  and  Technical  Agents. 
Responsibilities  include: 

(1)  Co-develop  FORCEnet  System  and  Technical  Criteria. 

(2)  Develop  the  FORCEnet  Integrated  Architecture 
System  Views  (SVs)  and  Technical  Views  (TVs)  in  coordination  with 
the  other  FORCEnet  stakeholders  and  SYSCOMs . 

(3)  Ensure  traceability  of  the  FCL  to  system  and 
technical  documentation  and  implementation  into  the  FORCEnet 
Integrated  Architecture. 

1 . 2  Acquisition  Management  Process 

1 . 3  Overview  of  the  Acquisition  Management  Process 

1.3.1  Integrated  Product  Teams  (IPTs) 

1.3. 1.1  Overarching  Integrated  Product  Teams  (OIPTs) 

OIPTs  are  generally  composed  of  SES  and  Flag  officers  with 
direct  knowledge  of  DoD,  DON,  and  Joint  mission  capabilities 
needs . 


1.3. 1.2  Working  Integrated  Product  Teams  (WIPTs) 

DASN (RDT&E)  CHSENG,  as  the  senior  technical  authority  for 
DON,  should  be  a  Working  IPT  (WIPT)  member  for  all  ACAT  I  and  IA 
programs  and  an  Acquisition  Coordination  Team  (ACT)  member  for 
other  Acquisition  Category  (ACAT)  programs  as  appropriate. 

1.3.2  Acquisition  Coordination  Teams  (ACTs) 

1 . 4  Categories  of  Acquisition  Programs  and  Milestone  Decision 
Authorities 


Annex  1-E  contains  the  contents  of  a  memorandum  for 
requesting  an  ACAT  designation  or  a  change  in  ACAT  designation. 

1 . 5  Capabilities  Development  and  Program  Decision  Points  and 
Phases 
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1.5.1  User  Needs  and  Technology  Opportunities 

1.5.2  Program  Tailoring 

1.5.3  Program  Decision  Points  Tailoring 

[ from  SNI  5000. 2E,  1.5.3  extract:  An  ACAT  program  does  not 
require  a  set  number  of  program  decision  points .] 

As  an  example  of  decision  point  tailoring,  it  is 
conceivable  that  a  Commercial-Of f-The-Shelf  (COTS)  acquisition 
strategy  could  have  program  initiation  at  a  combined  Milestone  C 
and  Full-Rate  Production  Decision  Review  (FRP  DR)  and  go  directly 
into  production  or  deployment.  Yet  there  are  certain  core 
activities  that  must  be  addressed  at  the  FRP  DR  such  as  need 
validation;  acquisition  strategy;  affordability,  life-cycle  cost, 
total  ownership  cost,  and  funding  adequacy;  industrial  base 
assurance  per  reference  (n) ;  risk  assessments  and  risk 
management;  interoperability  and  integration;  compliance  with  the 
legacy  joint  technical  architecture  that  has  been  replaced  with 
the  Global  Information  Grid  Technical  Guidance  (GTG)  which  now 
includes  the  DoD  Information  Technology  Standards  Registry 
(DISR) ;  supportability ;  safety  and  health;  environmental 
compliance;  and  operational  effectiveness  and  suitability  testing 
prior  to  an  FRP  decision  or  deployment,  or  subsequent  to  an  FRP 
decision  for  modifications.  Per  reference  (a),  all  of  these 
activities  shall  be  considered  in  light  of  the  other  systems  (and 
associated  programs)  in  a  SoS  or  FoS  and  the  impact  of  the 
introduction  of  a  new  program  on  the  mission  capability  of  a  SoS 
or  FoS . 

1.5.4  Program  Decision  Points  and  Phases 

1.5. 4.1  Materiel  Development  Decision  (MDD) 

1.5. 4. 2  Materiel  Solution  Analysis  (MSA)  Phase 

1.5. 4. 3  Milestone  A 

The  Technology  Development  Strategy  (TDS)  discussion  of 
the  viability,  feasibility,  and  applicability  of  technologies 
should  include  consideration  of  the  Human  Systems  Integration 
(HSI)  implications.  The  costs  associated  with  changes  to 
manpower,  personnel,  and  training  as  a  result  of  technology 
insertion  should  be  factored  into  any  affordability  assessment 
analysis  conducted  as  part  of  the  TDS  development.  The 
availability  of  trained  and  qualified  personnel  to  support  the 
technology  should  be  considered  in  assessments  of  feasibility  and 
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risk . 


1.5. 4. 4  Technology  Development  (TD)  Phase 

A  Pre-Engineering  and  Manufacturing  Development  (EMD) 
review  pursuant  to  PDUSD(ATSL)  memorandum  of  23  Jun  2011  as 
implemented  by  DASN (AP)  memorandum  of  26  Oct  2011  will  be  held 
during  this  phase  when  a  final  Request  for  Proposal  (RFP)  will  be 
released  prior  to  milestone  B  such  that  the  EMD  contract  can  be 
awarded  immediately  after  milestone  B  approval. 

Public  Law  111-23,  section  205,  requires  a  preliminary 
design  review  (PDR)  for  ACAT  I  programs  prior  to  milestone  B. 
Non-ACAT  I  programs  may  also  conduct  PDRs  prior  to  milestone  B  as 
determined  by  the  technology  development  strategy  for  the  TD 
phase  and  the  acquisition  strategy  for  the  EMD  phase. 

1.5. 4. 5  Milestone  B 

1.5. 4. 6  Engineering  and  Manufacturing  Development  (EMD) 

Phase 


1.5. 4. 6.1  Integrated  System  Design 

1.5. 4. 6. 2  Post-Preliminary  Design  Review  (PDR)  and 
Post-Critical  Design  Review  (CDR)  Assessments 

The  PM  may  propose  the  form  and  content  of  the  Post-PDR 
and  Post-CDR  Assessments  to  the  MDA  at  Milestone  B  for  inclusion 
in  the  ADM. 


1.5. 4. 6. 3  System  Capability  and  Manufacturing  Process 
Demonstration 


1.5. 4. 7  Milestone  C 

1.5. 4. 8  Production  and  Deployment  Phase 

1.5. 4. 9  Operations  and  Support  Phase 

1.5. 4. 9.1  Sustainment 

1.5. 4. 9. 1.1  Sustainment  Support 

See  ASN (RD&A)  memorandum  of  27  Jan  2003  for  Performance 
Based  Logistics  sustainment  support  guidance. 

1.5. 4. 9. 2  Disposal 
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As  the  total  life  cycle  manager,  PMs  consider  and  plan  for 
the  ultimate  demilitarization  and  disposal  of  the  system.  The  PM 
considers  materiel  demilitarization  and  disposal  during  systems 
engineering.  The  PM  carefully  considers  the  impacts  of  any 
hazardous  material  component  requirements  in  the  design  stage  to 
minimize  their  impact  on  the  life  cycle,  including  storage, 
packaging,  handling,  transportation  and  disposition.  The  PM 
coordinates  with  Service  logistics  activities.  Defense  Logistics 
Agency  (DLA) ,  and  CNO  (N43)  and  Naval  Sea  Systems  Command 
(NAVSEA) /Supervisor  of  Shipbuilding,  as  appropriate,  to  identify 
and  apply  applicable  demilitarization  requirements  necessary  to 
eliminate  the  functional  or  military  capabilities  of  assets  (see 
POD  4140 . 1-R,  DoD  Supply  Chain  Materiel  Management  Regulation, 
and  DOD  4160. 21-M,  Defense  Materiel  Disposition  Manual) . 

The  U.S.  Department  of  Labor,  Occupational  Safety  and 
Health  Administration  (OSHA) ,  has  a  National  Emphasis  Program  on 
shipbreaking  (ship  scrapping) ,  using  industry  best  practices  and 
electronic  Compliance  Assistance  Tools  (eCATs)  that  are  available 
on  the  OSHA  web  page  at  http : / / www . osha . gov/ .  The  National 
Institute  for  Occupational  Safety  and  Health  (NIOSH) ,  the 
occupational  safety  and  health  research  arm  of  OSHA  and  the  U.S. 
Department  of  Health  and  Human  Services,  Centers  for  Disease 
Control  (CDC) ,  are  establishing  a  comprehensive  listing  of 
industry  best  practices  for  ergonomic  interventions  in  the 
building,  repair,  and  dismantling  of  ships  that  is  available  on 
the  NIOSH  web  page  at 

http : / /www. cdc . go v/ niosh/ topics/ ergonomics/ ergship .  See 
reference  (o) ,  enclosure  2,  paragraph  8c (2),  and  DOD  4140. 1-R  and 
DOD  4160. 21-M  for  demilitarization  and  disposal  implementation 
requirements  for  DON  ACAT  programs. 

1.5.5  Modifications 

1.5.6  Additional  Procurement 

Changes  in  operational  environment  may  require  procuring 
additional  program  inventory  of  the  same  configuration  procured 
under  a  previous  ACAT  program  or  AAP  that  is  now  inactive.  In 
this  case,  a  new  ACAT  program  or  AAP  may  be  designated  as 
determined  by  the  procurement  cost/funding  level  relative  to  the 
ACAT  or  AAP  thresholds  of  table  E1T1  of  reference  (a) .  The 
acquisition  process  documentation  required  to  support  the  new 
ACAT  or  AAP,  per  tables  E2T1  and  E2T2  or  paragraph  1.4. 6.1  of 
reference  (a)  may  be  satisfied  by  tailoring  and/or  extrapolating 
from  the  previous  ACAT  program  or  AAP  acquisition  documentation 
as  appropriate.  The  new  program  must  use  the  most  recently 
validated  requirements  documentation  (ORD/CDD/CPD)  from  the 
previous  program.  Making  any  changes  to  the  program's 
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requirements  documentation  indicates  the  effort  is  a 
"modification,"  subject  to  the  policies  and  process  of  reference 
(a),  paragraph  1.5.5. 

1 . 6  Review  of  the  Legality  of  Weapons  Under  International  Law  and 

Compliance  with  Arms  Control  Agreements 

1.6.1  Review  of  the  Legality  of  Weapons  Under  International 

Law 


1.6.2  Review  for  Compliance  with  Arms  Control  Agreements 

The  DIRSSP  arms  control  review  and  certification  is  a 
technical  and  legal  assessment  independent  from  the  Judge 
Advocate  General/Law  of  Armed  Conflict  review  defined  in 
reference  (a),  paragraph  1.6.1.  DIRSSP  conducts  arms  control 
reviews  at  no  cost  to  the  program. 

Compliance  issues,  if  not  addressed  and  resolved  early, 
can  have  serious  programmatic  cost  ramifications  or  may  result  in 
program  cancellation.  Program  Managers  and  acquisition 
practitioners  are  responsible  for  ensuring  their  programs  are 
compliant  with  arms  control  treaties  and  agreements  at  every 
stage  of  the  acquisition  life  cycle.  Pursuant  to  SECNAVINST 
5420 . 188F,  enclosure  (2),  "Treaty  Compliance"  is  to  be  addressed 
at  each  milestone. 

1 . 7  Non-Acquisition  Programs 

Examples  of  non-acquisition  programs  are: 

a.  Science  and  Technology  (S&T)  Programs. 

(1)  Technology  based  programs  in  basic  research  (RDT&E 
Budget  Activity  (BA)  1)  and  applied  research  (RDT&E  BA  2)  (part 
of  Future  Naval  Capability  (FNC)  program) . 

(2)  Advanced  technology  development  (RDT&E  BA  3)  (part 
of  FNC  program) . 

b.  Developmental  or  operational  assessment  of 
developmental  articles,  concepts,  and  experiments  funded  by  RDT&E 
BA  4  or  BA  7  funding  and  with  no  directly  related  acquisition 
program  effort. 

c.  Management  and  support  of  installations  or  operations 
required  for  general-purpose  research  and  development  use 
(included  would  be  test  ranges,  maintenance  of  test  aircraft  and 
ships,  and  studies  and  analyses  not  in  support  of  a  specific 
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acquisition  program  research  and  development  effort)  funded  by 
RDT&E  BA  6  funding. 

1.7.1  Management  of  Non-Acquisition  Programs 

Non-acquisition  programs  will  be  managed  as  follows: 

Non-acquisition  programs  that  are  outside  of  the  FNC  and 
Innovative  Naval  Prototype  (INP)  review  process  will  be  reviewed 
annually  during  the  Program  Objective  Memorandum  (POM)  process 
by  CNO  resource  sponsors/CMC  (DC,  CD&I)  to  assess  progress  and 
verify  that  such  programs  are  pursuing  valid  Naval  requirements 
and  are  executing  per  the  applicable  Planning,  Programming, 
Budgeting,  and  Execution  System  (PPBES)  Research  and  Development 
Descriptive  Summary  (RDDS) .  Non-acquisition  programs  that  are 
FNC  projects  will  be  reviewed  annually  through  the  FNC  process 
to  assess  progress.  Non-acquisition  programs  require  a  DIRSSP 
arms  control  compliance  review. 

Navy  requests  to  initiate  a  non-acquisition  program 
funded  by  RDT&E  BA  4,  BA  6,  or  BA  7  will  be  submitted  to  a  CNO 
resource  sponsor  by  PEOs,  SYSCOMs,  DRPMs,  or  any  other 
appropriate  DON  activity.  Marine  Corps  requests  to  initiate  a 
non-acquisition  program  funded  by  RDT&E  BA  4,  BA  6,  or  BA  7  will 
be  submitted  to  CMC  (Deputy  Commandant,  Programs  and  Resources 
(DC,  P&R) ) . 

Approval  of  non-acquisition  programs  will  be  provided  by 
CNO  (N2/N6/N8)  or  CMC  (DC,  CD&I).  CNO  (N2 /N6/N8 ) /CMC  (DC,  CD&I) 
approval  constitutes  commitment  for  the  effort. 

Non-acquisition  programs  that  are  planned  for  transition 
into  a  related  ACAT  program  should  be  identified  in  the 
associated  RDDS.  Guidance  about  technology  transition  is 
provided  in  the  DUSD(S&T)  document,  "Technology  Transition  for 
Affordability,  A  Guide  for  S&T  Program  Managers "  of  April  2001 
and  OUSD (AT&L) DP&AP  document,  "Manager' s  Guide  to  Technology 
Transition  in  an  Evolutionary  Acquisition  Environment  Version 
1.0  of  31  January  2003."  The  second  document  can  be  accessed  at 
http : / /www. acq.osd.mil/jctd/ articles /AQ20 IS lvlOComplete .pdf . 


Per  reference  (a) ,  a  listing  of  all  approved  non¬ 
acquisition  programs  shall  be  provided  to  DASN (RD&A) (Management 
and  Budget) (M&B)  annually  by  CNO  (N8)/CMC  (DC,  CD&I). 

1 . 8  Urgent  Capability  Needs  and  Acquisition  Processes 

1.8.1  DON  Urgent  Needs  Process  (UNP) 

Responsibilities .  All  DON  organizations  should  ensure 
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implementation  of  the  UNP  so  that  the  best  available  solutions  to 
mission-critical  capability  gaps  are  provided  in  less  than  24 
months . 


a .  Chief  of  Naval  Operations  (CNO) /Commandant  of  the 
Marine  Corps  (CMC) 


(1)  Provide  end-to-end  visibility  and  tracking  of 
urgent  needs  from  submission  to  resolution. 

(2)  Designate  a  single  point  of  entry  for  urgent  needs 

submission . 

(3)  Ensure  every  urgent  need  is  thoroughly  vetted  at 
appropriate  levels  throughout  the  chain  of  command. 

(4)  Establish  and  lead  cross-functional  solution 
development  teams. 

(5)  Identify  resources  and  prioritize  offsets  to 
satisfy  urgent  needs. 

(6)  Evaluate,  approve,  and/or  request  further  action 
on  the  recommendations  defined  in  the  solution  strategy. 

(7)  Identify  sustainment  needs  and  execute  as 

necessary . 

(8)  Collect  feedback  to  assess  suitability, 
supportability,  and  sustainability. 

(9)  Ensure  every  capability  gap  identified  as  an 
urgent  need,  regardless  of  resolution,  is  entered  into  the 
deliberate  process  for  further  consideration  as  an  enduring 
requirement . 


(10)  Continuously  improve  Service  procedures. 

b .  Assistant  Secretary  of  the  Navy  (Research,  Development 
and  Acquisition) 


(1)  Provide  technical  and  acquisition  expertise  to 
support  cross-functional  solution  development  team. 

(2)  Direct  and  oversee  acquisition  activities  in 
support  of  approved  solutions. 

(3)  Ensure  appropriate  testing  of  materiel  solutions 
is  completed  prior  to  delivery. 
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(4)  Provide  initial  sustainment  as  required. 

(5)  Provide  regular  information  updates  concerning  the 
procurement  and  delivery  of  materiel  solutions. 

(6)  Continuously  improve  the  UNP . 

(7)  Provide  arms  control  implementation  and  compliance 

oversight . 

c .  Assistant  Secretary  of  the  Navy  (Financial  Management 
and  Comptroller) 


(1)  Provide  financial  management  expertise  to  support 
the  cross-functional  solution  development  team. 

(2)  Assist  cross-functional  solution  development  team 
to  identify  funding  strategy  with  support  as  required  from  Navy 
and  Marine  Corps  resource  sponsors. 

d .  Supported  Commanders  of  Marine  Forces 


(1)  Review,  certify,  and  forward  urgent  need  requests 
that  cannot  be  resolved  with  organic  resources. 

(2)  Provide  operational  expertise  to  support  cross¬ 
functional  solution  development  team. 

(3)  Provide  feedback  on  the  suitability, 
supportability,  and  sustainability  of  the  delivered  capabilities 
via  the  UNP  to  enable  continued  improvements  to  interim  solutions 
and  influence  the  deliberate  process. 

e.  United  States  Fleet  Forces  Command 


(1)  Review  the  Navy  Component  Commander  submitted 
urgent  need,  endorse  the  requirement,  and  forward  urgent  needs 
requests  that  cannot  be  resolved  with  Fleet  resources. 

(2)  Provide  operational  expertise  to  support  cross¬ 
functional  solution  development  team. 

(3)  Provide  feedback  on  the  suitability, 
supportability,  and  sustainability  of  the  delivered  capabilities 
via  the  UNP  to  enable  continued  improvements  to  interim  solutions 
and  influence  the  deliberate  process. 

1.8.2  Rapid  Deployment  Capability  (RPC)  Process  and 
Procedures 
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1.8.3  Rapid  Development  and  Deployment  (RDD)  Process  and 
Procedures 


1 . 9  Executive  Review  Procedures 

1.9.1  DON  Program  Decision  Process 

Per  reference  (a) ,  recommendations  to  the  MDA  regarding 
program  continuance  shall  address  logistics  and  sustainment 
factors  in  balance  with  other  major  decision  factors.  Per 
reference  (a),  for  joint  Service  programs  where  the  Navy  or 
Marine  Corps  is  the  lead  or  joint  program  manager  (including 
joint  Service  programs  where  the  Navy  or  Marine  Corps  is  the 
executive,  participating,  or  lead  Service)  responsible  for 
introducing  systems  to  be  operated,  maintained,  and/or  supported 
by  Navy  or  Marine  Corps  forces,  independent  logistics  assessments 
shall  be  conducted  and  the  results  of  the  assessments  certified 
for  the  planned  Navy/Marine  Corps  assets. 

1.9.2  IT  Acquisition  Board  (ITAB)  Reviews 

1.9.3  DoD  Space  System  Acquisition  Process  Guidance 

[ from  SNI  5000.2E,  1.9.3:  The  Under  Secretary  of  Defense 
for  Acquisition ,  Technology  and  Logistics  is  the  DoD  space  MDA 
for  all  DoD  space  MDAPs  (ACAT  I  programs) .  The  responsibility 
for  the  execution  of  DoD  space  systems  flows  from  the  DoD  space 
MDA  through  each  CAE  to  the  appropriate  PEO  and  PM.  Reference 
(v)  {in  SECNAVINST  5000. 2E}  provides  the  necessary  interim 
guidance  and  procedures  for  these  programs .] 

USD(AT&L)  Directive-Type  Memorandum  (DTM)  09-025,  Space 
Systems  Acquisition  Policy  (SSAP) ,  of  18  Oct  2010  cancelled 
reference  (v)  in  SECNAVINST  5000. 2E  and  amended  DoD  Instruction 
5000.02.  DTM  09-025  provides  updated  policy  and  procedures  for 
acquisition  of  military  space  systems. 

1.9.4  Defense  Business  System  Management  Committee  (DBSMC) 
Certification  and  Approval 

1.9. 4.1  Defense  Business  System  Definition 

1.9. 4. 2  Roles  and  Responsibilities 

1.10  Source  Selection  Authority  (SSA) 

1.10.1  ACAT  I,  IA,  and  II  Programs 
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1.10.2  ACAT  III,  IV,  and  Abbreviated  Acquisition  Programs 

1.10.3  Other  Competitively  Negotiated  Acquisitions 

1.10.4  Source  Selection  Advisory  Council  (SSAC) 

An  SSAC  will  consist  of  a  chair,  appointed  by  the  SSA,  and 
other  senior  military  and  civilian  personnel,  appointed  by  the 
SSAC  Chair,  to  act  as  advisors  throughout  the  source  selection 
process.  The  SSAC  Chair  will  ensure  that  Source  Selection 
Evaluation  Board  (SSEB)  members  are  adequately  trained  with 
respect  to  the  statement  of  work,  evaluation  criteria,  evaluation 
methodology,  current  procurement  laws,  and  documentation 
requirements.  The  SSAC  will  normally  include  representatives 
from  the  various  functional  areas  involved  in  the  procurement. 
While  not  an  SSAC  member,  legal  counsel  normally  will  be 
available  to  advise  the  SSAC.  The  SSAC  will  ensure  the 
evaluation  was  conducted  and  documented  per  the  Source  Selection 
Plan  and  will  prepare  a  written  source  selection  recommendation 
for  the  SSA. 

1.10.5  Source  Selection  Evaluation  Board  (SSEB) 

An  SSEB  will  consist  of  a  chair,  appointed  by  the  SSAC 
Chair,  and  other  qualified  Government  contracting,  technical  and 
administrative/management  personnel  appointed  by  the  SSEB  Chair, 
to  direct,  control  and  perform  the  evaluation  of  proposals  and  to 
produce  facts  and  findings  required  in  the  source  selection 
process.  A  technical  evaluation  team  composed  of  knowledgeable 
and  professionally  competent  personnel  in  appropriate  specialty 
areas  may  assist  an  SSEB.  Such  personnel  should  have  previous 
experience  in  similar  or  related  programs  so  as  to  provide  mature 
judgment  and  expertise  in  the  evaluation.  Non-government 
personnel  may  not  be  members  of  an  SSEB.  While  not  an  SSEB 
member,  qualified  legal  counsel,  different  from  an  SSAC  legal 
counsel,  normally  should  be  available  to  advise  an  SSEB. 

1.10.6  ASN (RD&A)  Source  Selection  Briefing 

For  ACAT  I  and  II  programs,  the  SSA  will  ensure  that 
ASN (RD&A) ,  or  cognizant  DASN,  is  briefed  on  the  principal  results 
of  the  source  selection  decision  prior  to  contract  award (s)  and 
prior  to  the  public  announcement  of  such  award (s) . 

1.11  Two-Pass/Six-Gate  DON  Requirements  and  Acquisition 
Governance  Process 


1.11.1  Purpose 
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1.11.2  Objective 

1.11.3  Scope  and  Applicability 

1.11.4  Organization  and  Procedures 

1.11.4.1  Materiel  Development  Decision  and  Materiel 
Solution  Analysis  Phase 

1.11.4.1.1  Pass  1 

1.11.4.1.1.1  Gate  1 

1.11.4.1.1.2  Gate  2 

1.11.4.1.1.3  Gate  3 

1.11.4.2  Milestone  A  and  Technology  Development  Phase 

1.11.4.2.1  Pass  2 

1.11.4.2.1.1  Gate  4 

1.11.4.3  Milestone  B  and  Engineering  and  Manufacturing 
Development  (EMD)  Phase 

1.11.4.3.1  Pass  2 

1.11.4.3.1.1  Gate  5 

1.11.4.3.1.2  Gate  6 

1.11.4.4  DON  Reguirements/Acguisition  Gate  Review 
Membership 

1.11.4.4.1  Chairperson 

1.11.4.4.2  Principal  Members 

1.11.4.4.3  Advisory  Members 

1.11.4.5  DON  Reguirements/Acguisition  Individual  Gate 
Membership  and  Entrance/Exit  Criteria 

Individual  Gate  exit  criteria  templates  are  contained  in 
chapter  1,  annex  1-F.  A  Gate  6  Configuration  Steering  Board 
(CSB)  briefing  content  template  is  contained  in  chapter  1,  annex 

1-G. 
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1.11.4.6  System  Design  Specification  (SDS)  Description 

1.11.5  Responsibilities 

1.11.5.1  ASN (RD&A) 

1.11.5.2  CNO/CMC 

1.11.5.2.1  DCNO  (N8)/DC,  CD&I 

1.11.5.2.2  CNO/CMC  Staff  Principal  and  Advisory 

Members 

1.11.5.3  Program  Executive  Officers  (PEOs) /Systems 
Commands  (SYSCOMs)  Commanders 

1.11.5.4  ASN (FM&C) 

1.11.5.5  OGC 

1.11.6  Industry  Involvement 
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Annex  1-A  Navy  Requirement/Capability  Documents  Flow 
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*  Durations  with  asterisks  are  defined  in  relevant  instruction 
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Notional  Timeline:  JROC  Interest  Document 

Navy  Review  and  Board: 
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Joint  Review: 
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Annex  1-B 

Initial  Capabilities/Capability  Development/Production  Document 


Signature  Page 

(Insert  Document  Type  Here) 

FOR 

[TITLE  OF  PROGRAM] 

(POTENTIAL  ACAT  LEVEL  /UPCOMING  MILESTONE 

Serial  Number  (*) : 

) 

SUBMITTED: 

(PROGRAM  SPONSOR) 

(DATE) 

ENDORSED  and  FORWARDED: 

(N2/N6F)  (FORCEnet  Compliance) 

(DATE) 

(N83) 

(DATE) 

APPROVED  and  VALIDATED:  (JOINT  INTEGRATION  and  Below) 

(N80)  (NCB  Chair,  as  required) 

(DATE) 

(N8 )  (R3B  Chair) 

(DATE) 

REVIEWED: 

(USFF  N00) 

(DATE) 

(VCNO) 

(DATE) 

APPROVED  and  VALIDATED:  (JROC  INTEREST) 

(CNO)  (*/**) 

(DATE) 

(JROC)  (*/**) 

(DATE) 

[Guide  only.  Actual  format  to  be  tailored  by  program  sponsor  and  CNO  (N83) ] 

(*)  -  CNO  (N83)  will  assign  serial  number  once  validated  and  approved.  For  ACAT  ID 

programs,  CNO  (N83)  will  insert  JROC  validation  and  approval  date  prior  to 
issuance . 

(**)  -  JROC  validates  and  approves  unless  delegated.  The  signature  page  will  be 
tailored  accordingly. 
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Annex  1-C 

Initial  Capabilities  Document  (ICD)  Content  Guidance 


See  reference  (k)  ,  enclosure  B,  paragraph/section  4.,  for 
initial  capabilities  document  (ICD)  format  and  page  limits. 

Reference  (k)  ,  enclosure  B,  ICD  format 
subparagraphs/subsections  c. (6) ,  c. (7) (a) ,  c. (7) (b) ,  and 
c. (7) (c) ,  will  be  implemented  for  Navy  systems  as  amplified  below 
in  this  annex. 

c .  Section  Descriptions 


(6)  Assessment  of  Non-Materiel  Approaches  [Doctrine, 
Organization,  Training,  Materiel,  Leadership  and  education. 
Personnel,  Facilities,  and  Policy  (DOTMLPF-P)  Analysis] 

Summarize  the  changes  to  DOTMLPF-P  considered  during  the 
Capabilities  Based  Assessment  or  other  analysis  and  explain  if 
changes  in  manpower,  personnel  and  training  concepts,  policy  and 
practices  would  satisfy  the  capability  gaps  in  part  or  in  whole. 
Include  consideration  of  capabilities  in  Allied/partner  nations, 
the  interagency,  and  other  DoD  Components.  It  should  also 
summarize  whether  accomplishment  of  minor  human  factors 
engineering  modifications  to  existing  systems  could  enhance 
current  system  performance  enough  to  meet  the  deficiency  within 
the  reguired  safety,  personnel  survivability  and  habitability 
reguirements .  Discussion  of  these  analyses,  and  reasons  why 
changes  in  DOTMLPF-P/Human  Systems  Integration  (HSI)  will  not 
satisfy  the  need,  should  be  specific.  A  blanket  statement  that 
DOTMLPF-P  changes  alone  will  not  satisfy  the  deficiencies  is 
neither  useful  nor  adequate. 

(7)  Final  Recommendations 


(a)  Identify  DOTMLPF-P  recommendations  to  be 
considered  as  part  of  a  materiel  solution.  Proponents  should 
consult  with  the  Navy  IPO  for  assistance  and  guidance  in  meeting 
the  reference  (b)  requirements  for  examination  of  existing  or 
future  allied  military  systems  and  for  recommended  approaches  to 
including  international  considerations  in  the  materiel  approach. 

(b)  Identify  DOTMLPF-P  recommendations  to  be 
considered  independent  of  a  materiel  solution.  Per  reference 
(k) ,  HSI  constraints  that  impact  concept  feasibility,  total 
system  performance  and  affordability  shall  be  included  in  Section 
(7) (b)  of  the  ICD  as  key  boundary  conditions  of  the  Analysis  of 
Alternatives  (AoA) .  Section  (7) (b)  of  the  ICD  should  describe 
the  DOTMLPF-P  and  policy  implications  and  constraints  to  include 
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all  HSI  domains.  Examples  of  HSI  implications  and  constraints 
may  include:  end-strength  limitations  for  manpower;  affordability 
of  developing  and  training  new  Knowledge,  Skills  and  Abilities 
(KSAs)  not  currently  available  in  the  Navy  personnel  inventory; 
minimums  and  appropriate  mix  of  manpower  (military,  civilian  and 
contractor) ,  and  habitability  and  workspace  safety  and 
occupational  health  compliance  requirements.  Other  HSI-related 
information  relevant  to  system  design  should  be  provided  as 
guidance  in  these  sections  of  the  ICD. 

(c)  For  all  capability  requirements  that  cannot  be 
met  using  non-materiel  approaches,  make  specific  recommendations 
on  the  type  of  materiel  approach  preferred  to  close  each 
capability  gap,  which  may  be  used  by  the  MDA  to  adjust  the  scope 
of  the  AoA. 


1  Enhancement  of  an  Existing  System. 

2_  Replacement  or  Recapitalization  of  an  Existing 

System . 


3  Development  of  a  New  Capability  Solution, 
d .  Appendices 


(1)  Appendix  A.  Architectural  Data.  Include  the  link(s) 
to  the  required  architecture  data  identified  in  reference  (k) , 
Table  B-F-3.  Other  than  the  OV-1,  do  not  include  the  diagrams 
themselves  unless  specifically  referenced  for  illustration 
purposes  elsewhere  in  the  body  of  the  ICD. 
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Annex  1-D 

Capability  Development/Production  Document  (CDD/CPD)  Content 

Guidance 


See  reference  (k) ,  enclosure  B,  paragraph/section  7./8., 
for  CDD/CPD  formats  and  page  limits. 

Reference  (k)  ,  enclosure  B,  CDD/CPD  format 
subparagraphs/subsections  c.  (6)  (d)  ,  c.  (6)  (e)  ,  c.  (8)  ,  c.  (14)  , 
c. (15),  and  c. (16)  and  appendices,  will  be  implemented  for  Navy 
systems  as  amplified  below  in  this  annex. 

c .  Section  Descriptions 

( 6)  Development  or  Production  Key  Performance  Parameters 
(KPPs) ,  Key  System  Attributes  (KSAs) ,  and  additional  performance 
attributes 


(a)  Sponsors  must  consider  the  six  "required"  KPPs 
detailed  in  reference  (k) ,  Enclosure  B,  Appendix  A. 

(b)  Sponsors  shall  avoid  over  specification  of 

KPPs /KSAs . 

(c)  Provide  a  description  of  each  attribute  and  list 
each  attribute  in  a  separate  numbered  paragraph. 

(d)  Present  each  attribute  performance  threshold  and 
objective  in  output-oriented,  measurable,  and  testable  terms. 

Base  all  performance  thresholds  on  an  analysis 
of  mission  demands  and  comparable  fleet  and  commercial  system 
experience.  The  degree  of  attribute  performance  specificity,  in 
setting  initial  threshold  and  objective  values,  is  to  be  tailored 
to  the  system  and  the  acquisition  phase. 

(e)  Provide  tables  summarizing  specified  KPPs,  KSAs, 
and  additional  performance  attributes  in  threshold/ob j ective 
format.  System  supportability  and  manpower  are  specifically 
described  in  paragraphs  (6)  (e)jL  and  (6)  (e).2  below. 

1  System  supportability  shall  be  a  performance 
parameter  per  reference  (k)  as  described  below: 

a  Mission  Capable/Full  Mission  Capable 
(MC/FMC)  rates,  focused  on  primary  mission  areas  may  be  used  as 
supportability  performance  parameters  in  CDDs  and  CPDs  for 
aircraft  or  ship  platforms. 
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b  Materiel  Availability  and  Operational 
Availability  shall  be  mandatory  sustainment  KPPs  per  references 
(b)  and  (k)  . 


c  For  legacy  system  modifications,  sustainment 
parameters  should  be  key  performance  parameters.  Materiel 
Availability  and  Operational  Availability  shall  be  mandatory 
sustainment  KPPs  for  only  those  subsystems  being  upgraded. 

2_  Manpower  may  be  a  KPP  for  selected  systems  as 
jointly  determined  by  the  program  sponsor  and  the  Manpower 
Sponsor  (CNO  (Nl) ) .  Program  sponsors  should  assume  a  default 
consideration  for  a  manpower  KSA  unless  they  obtain  prior 
agreement  with  CNO  (Nl) . 

j3  Readiness  thresholds,  normally  supportability 
performance  parameters  or  KPPs,  should  account  for  all  system 
downtime,  including  scheduled  maintenance. 

■4  Diagnostics  effectiveness  thresholds  should  be 
established  for  systems  whose  faults  are  to  be  detected  by 
external  support  equipment  or  Built-In-Test  (BIT) .  Threshold 
parameters  should  include  percent  correct  fault  detection  and 
percent  correct  fault  isolation  to  a  specified  ambiguity  group. 
False  alarm  parameters  should  state  thresholds  in  time  (i.e.  Mean 
Time  Between  False  Alarms)  or  in  percent. 

_5  Materiel  Reliability  and  Ownership  Cost  shall 
be  mandatory  Key  System  Attributes  (KSAs)  per  references  (b)  and 
(k) .  Measures  of  operational  system  reliability  should  consist 
of  both  mission  and  logistics  reliability  parameters,  as 
appropriate.  Mean  Time  Between  Operational  Mission  Failure 
(MTBOMF)  should  be  used  as  the  mission  reliability  parameter. 

Mean  Time  Between  Failure  (MTBF)  should  be  used  as  the  logistics 
reliability  parameter.  These  parameters  should  be  used  as  the 
operational  system  reliability  parameters  during  OT&E,  including 
Initial  Operational  Test  and  Evaluation  (IOT&E). 

( 8 )  Spectrum  Requirements 


(a)  Establish  E3  protection  and  spectrum 
supportability  requirements  for  the  following: 

1  Hazards  of  Electromagnetic  Radiation  to 

Ordnance  (HERO) 

2  Hazards  of  Electromagnetic  Radiation  to 

Personnel  (HERP) 

3_  Hazards  of  Electromagnetic  Radiation  to  Fuel 
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(HERF) 


4  Electromagnetic  Pulse  (EMP) 

_5  Electromagnetic  Emission  Control  (EMCON) 

6_  Electromagnetic  Emissions  Security  (EMSEC) 
1_  Electrostatic  Discharge  (ESD) 

8^  Precipitation  Static  (P-Static) 

9_  Lightning  protection 

10  Range  of  frequency  operations  including 
within  host,  allied,  and  coalition  nations 

1 1  Threat  emitters 

( 14 )  Doctrine,  Organization,  Training,  materiel. 
Leadership  and  education.  Personnel,  Facilities,  and  Policy 
(DOTMLPF-P)  Considerations 


(a)  HSI  considerations  that  have  a  major  impact  on 
system  effectiveness,  suitability,  and  affordability  should  be 
addressed  in  section  15.  The  DOTMLPF-P  implications,  to  include 
all  the  HSI  domains,  associated  with  deploying/f ielding  the 
system  should  be  discussed  in  section  15  of  the  CDD  and  CPD. 

This  section  should  provide  a  short  description  of  the  HSI  issues 
and  Fleet  concerns  regarding  implementation  of  the  materiel 
solution.  This  section  should  describe  the  safety  and 
occupational  health  requirements,  and  environmental  compliance 
expectations  and  associated  costs. 

(15)  Other  System  Attributes 


(a)  Capabilities-oriented,  performance-based  HSI 
requirements  that  drive  design,  cost,  and/or  risk  should  be 
included  in  section  15  of  the  CDD  and  CPD.  HSI  performance 
requirements  should  be  specific  and  explicit  in  identifying  the 
human  performance  contribution  required  to  ensure  total  system 
performance  and  mission  success.  HSI  performance  requirements 
should  optimize  human-machine  performance  under  operational 
conditions.  HSI  requirements  should  include  thresholds  and 
objectives  and  identify  the  Measures  of  Effectiveness  (MOEs) . 
Statements  describing  analyses  that  lead  to  specific  human 
performance  requirements  should  be  avoided  unless  the  level  of 
fidelity  of  the  Concept  of  Operations  (CONOPS) ,  program  or 
technology  is  lacking.  These  analyses  should  be  conducted  as 
part  of  the  requirements  determination  effort  similar  to  any 
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other  system  component.  When  fidelity  is  lacking,  section  15 
should  contain  broad  constraints  for  the  HSI  requirements  so  that 
future  revisions  of  the  CDD  will  represent  a  refinement  of  the 
requirements  and  not  the  addition  of  new  requirements.  HSI 
requirements  should  address,  but  are  not  limited  to: 

1  Broad  manpower  constraints  for  the  minimum 
number  and  appropriate  mix  (military,  civilian  and  contractor)  of 
operators,  maintainers,  trainers  and  support  personnel. 

2  Manpower  factors  that  impact  system  design 
(e.g.,  utilization  rates,  pilot-to-seat  ratios,  maintenance 
concepts) . 


3  Identification  of  required  Knowledge,  Skills 
and  Abilities  (KSAs) ,  aptitudes  and  physical  characteristics  of 
operators,  maintainers  and  support  personnel. 

_4  Requirements  for  the  training  support  package 
and  logistics  (e.g.,  technical  documentation,  simulators, 
training  devices,  new  learning  techniques,  simulation  technology, 
embedded  training) ;  requirements  for  individual,  collective  and 
joint  training  for  operators,  maintainers  and  support  personnel. 

_5  Human  performance  requirements  that  contribute 
to  total  system  performance  and  mission  success;  the  cognitive, 
sensory  and  physical  requirements  of  the  operators,  maintainers 
and  support  personnel;  ergonomic  requirements  for  visual  displays 
and  their  images,  keyboards  and  other  Input/Output  (I/O)  devices, 
workstations,  and  the  operational  environment;  constraints  or 
limitations  on  size  or  layout  of  system,  equipment,  and/or 
workspace.  Skills-based  human  performance  requirements  should  be 
identified,  developed  in  compliance  with  the  sharable  content 
object  reference  model  (SCORM) ,  and  grouped  to  form  the  basis  for 
capability  based  and  competency  driven  structured  learning 
methodologies  necessary  to  improve  human  performance. 

6  System  safety  and  occupational  health 
requirements  that  will  eliminate,  reduce,  and  mitigate  the 
potential  for  injury,  illness  or  disability  and  death  of  the 
operators,  maintainers  and  support  personnel. 

1_  System  requirements  that  reduce  the  risk  of, 
prevent  fratricide,  and/or  increase  the  odds  of  surviving 
fratricide,  personal  detection  or  targeting,  or  confinement 
within  an  attacked  entity.  Examples  include  egress  from  confined 
spaces,  location  of  berthing  and  mess  facilities  within  a  ship  or 
submarine,  ejection  seats  and  assisted  breathing  devices. 

8_  Personnel  support  service  requirements  such  as 
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berthing  and  personal  stowage,  food  service,  medical,  chapel  and 
brig  facilities,  recreational  and  lounge  spaces;  ambient 
environment  requirements  (e.g.,  noise,  lighting.  Heating, 
Ventilation,  and  Air  Conditioning  (HVAC) ) . 

(b)  As  appropriate,  address  attributes  that  tend  to 
be  design,  cost,  and  risk  drivers,  including  Environment,  Safety, 
and  Occupational  Health  (ESOH)  quality;  information  protection 
standards  for  Intelligence,  Surveillance,  and  Reconnaissance 
(ISR)  platforms  and  other  platforms  as  required;  and  Information 
Assurance  ( IA) . 

(c)  Address  safety  issues  regarding  Hazards  of 
Electromagnetic  Radiation  to  Ordnance  (HERO) . 

(d)  Identify  system  data  standards,  data  accuracy, 
and  data  forecast  required  for  net-centric  data  interoperability. 

(e)  Identify  weather,  oceanographic, 

astrogeophysical ,  geospatial,  and  time  support  needs  throughout 
the  system's  expected  life-cycle.  Standard  geospatial  reference 
frame  is  defined  by  the  World  Geodetic  System  1984  (WGS-84) . 

Time,  in  terms  of  the  standard  temporal  reference,  is  defined  by 
Coordinated  Universal  Time  (UTC)  as  maintained  by  the  U.S.  Naval 
Observatory  (USNO)  Master  Clock,  which  is  the  standard  for 
military  systems. 

(16)  Program  Affordability 


(a)  Operations  and  Support  (O&S)  Cost 

Per  reference  (k) ,  O&S  shall  be  established  as  a  cost 
parameter  starting  with  the  initial  system  CDD/CPD.  Specifying 
O&S  cost  criteria  with  an  associated  threshold  and  objective 
places  emphasis  on  optimizing  the  most  significant  portion  of 
program  cost.  The  methodology  by  which  this  parameter  should  be 
measured  should  be  made  clear  by  the  requirements  sponsor  in  the 
CDD/CPD,  and  involves  concurrence  with  the  testing  community, 
cost  estimators,  and  the  system  program  office. 

d .  Appendices 

(1)  Appendix  A.  Net-Ready  Key  Performance  Parameter 
(KPP)  Architecture  Data.  Include  the  links  to  the  architecture 
repository  for  the  required  NR  KPP  architecture  data  identified 
in  reference  (k) ,  Enclosure  B,  Appendix  F,  Table  B-F-3.  Other 
than  the  OV-1,  do  not  include  the  NR  KPP  architecture  data  unless 
specifically  referenced  for  illustration  purposes  somewhere  in 
the  body  of  the  CDD  or  CPD.  Formatting  instructions  are  provided 
in  DoD  Architecture  Framework,  Version  2.0,  of  28  May  09. 
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Annex  1-E 

Weapon  System  and  IT  System  Programs 
ACAT  Designation/Change  Request  (Content) 


The  memorandum  requesting  an  Acquisition  Category  (ACAT) 
designation  or  requesting  a  change  in  ACAT  designation  should  be 
sent  to  ASN (RD&A)  for  ACAT  ID,  IC,  IAM,  IAC,  and  II  programs  via 
the  PEO/SYSCOM/DRPM,  or  to  the  cognizant  PEO/SYSCOM/DRPM  for 
weapon  system  or  IT  system  ACAT  III  and  ACAT  IV  programs,  and 
should  contain  the  following  information: 

a.  Acquisition  program  short  and  long  title. 

b.  Prospective  claimant/SYSCOM/PEO/DRPM/PM. 

c.  Prospective  funding:  (where  known) 

(1)  Appropriation  (APPN) :  [repeat  for  each  appropriation] 

(a)  [Repeat  for  each  program  element  (PE) /Line 
Item  (LI ) /Sub-pro j ect  (Sub)] 

-  Program  Element  (No. /Title) : 

-  Project  Number/Line  Item  (No. /Title): 

-  Sub-pro j ect/Line  Item  (No. /Title): 

-  Budget:  [FY-2000  constant  dollars  in  millions] 


Current 

FY 

Budget 

FY 

FY 

FY 

FY 

FY 

FY 

FY 

To 

Complete 

Total 

d.  Program  description.  (Provide  a  brief  description  of  the 
program,  including  its  mission.) 

e.  List  Initial  Capabilities  Document,  Capability 
Development/Production  Document,  and  respective  approval 
dates . 

f.  Program  decision  point  status.  (List  completed 
milestones  and  dates;  list  scheduled  program  decision 
points  and  dates.) 

g.  Recommended  ACAT  assignment,  or  change,  and  rationale. 

Copy  to:  ASN  (RD&A)  [ACAT  III  and  IV  programs] 

DASN (M&B)  [all  ACAT  programs] 

DASN (RD&A)  [cognizant  DASN  for  all  ACAT  programs] 

CNO  (N8/N84)  [All  Navy  ACAT  programs] 

CMC  (DC,  CD&I)  [All  Marine  Corps  ACAT  programs] 
COMOPTEVFOR  [All  Navy  ACAT  programs] 

Dir,  MCOTEA  [All  Marine  Corps  ACAT  programs] 
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Annex  1-F 

DON  Requirements/Acquisition  Gate  1  ICD 
Exit  Criteria  Template  [Templates  moved  here  from  inst] 


1.  Approval  for  ICD  entry  into  joint  review,  or  endorsement  of 
ICD  enroute  to  CNO/CMC  for  signature. 

2.  Validation  of  AoA  Study  Guidance,  assumptions,  and  timeline 
and  authorization  for  submittal  to  Director,  Cost  Assessment  and 
Program  Evaluation  (CAPE)  (ACAT  I  and  IA) ,  or  approval  of  AoA 
guidance,  assumptions,  and  timeline  (selected  ACAT  II). 

3.  Concur  with  associated  DOTMLPF-P  Change  Recommendations 
( DCRs )  . 

4.  Satisfactory  review  of  program  health. 

5.  Approval  to  proceed  to  the  next  Gate  Review. 

6.  Approval  to  proceed  to  MDD. 
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Annex  1-F 

DON  Requirements/Acquisition  Gate  2  AoA 
Exit  Criteria  Template 

1.  Evaluation/Validation  of  AoA  findings. 

2.  Approve  initial  capabilities  thresholds  and  objectives 
(KPPs/KSAs) . 

3.  Approval  to  develop  CDD  and  CONOPS  with  guidance  and 
assumptions  documented  in  a  decision  memorandum. 

4.  Satisfactory  review  of  program  health. 

5.  Concurrence  to  proceed  to  the  next  event  (i.e.,  to  Gate  3) . 
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Annex  1-F 

DON  Requirements/Acquisition  Gate  3  CDD/CONOPS 
Exit  Criteria  Template 


1.  Approval  of  initial  CDD  enroute  to  CNO  or  CMC  for  signature. 

2.  Approval,  or  endorsement,  of  CONOPS . 

3.  Validation  of  the  SDS  development  plan  and  outline. 

4.  Determination  of  potential  for  export/co-development . 

5.  Concur  with  initial  life-cycle  sustainment  strategy. 

6.  Validate  program  assumptions  as  reflected  in  the  Cost 
Analysis  Requirements  Description  (CARD) . 

7.  Satisfactory  review  of  program  health. 

8.  Concurrence  with  draft  TDS,  TES,  and  SEP. 

9.  Approval  of  full  funding  certification  for  MS  A. 

10.  Approval  to  proceed  to  MS  A. 
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Annex  1-F 

DON  Requirements/Acquisition  Gate  4  SDS 
Exit  Criteria  Template 


1.  Approved  SDS. 

2.  Validate  SDS  traceability  to  CDD. 

3.  Acknowledgement  of  configuration  steering  board  (CSB) 
recommended  capability  changes.  Approval  to  proceed  to  R3B/MROC, 
or  CNO/CMC,  for  assessment  and  Service  approval. 

4.  Sufficiently  structured  to  operate  within  DON'S  business 
enterprise . 

5.  Satisfactory  review  of  program  health. 

6.  Approval  to  proceed  to  the  next  event. 


1-49 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


Annex  1-F 

DON  Requirements/Acquisition  Gate  5  RFP 
Exit  Criteria  Template 


1.  Approval  for  RFP  release,  and  the  next  acquisition  event,  as 
authorized  by  the  Acquisition  Strategy. 

2.  Authorization  to  proceed  to  MS  B  defense  acquisition  board 
(DAB)  or  approval  of  MS  B  if  MDA  is  ASN (RD&A) . 

3.  Approve  APB  and  full  funding  certification  for  MS  B. 

4.  Acknowledgement  of  CSB  recommended  capability  changes. 
Approval  to  proceed  to  R3B/MROC,  or  CNO/CMC,  for  assessment  and 
Service  approval. 

5.  Satisfactory  review  of  program  health. 
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Annex  1-F 

DON  Requirements/Acquisition  Gate  6  Post-IBR 
Exit  Criteria  Template 


1.  Performance  measurement  baseline  (PMB)  established  and 
integrated  baseline  review  (IBR)  results  acceptable. 

2.  Contractor's  PMB  meets  the  SDS  requirements. 

3.  Acknowledgement  of  CSB  recommended  capability  changes; 
approval  to  proceed  to  R3B/MROC,  or  CNO/CMC,  for  assessment  & 
Service  approval. 

4.  Satisfactory  review  of  program  health. 
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Annex  1-F 

DON  Requirements/Acquisition  Gate  6  CPD 

Exit  Criteria  Template 

1.  Approval  for  CPD  entry  into  joint  review,  or  endorsement  of 
CPD  enroute  to  CNO/CMC  for  signature. 

2.  Authorization  to  proceed  to  DAB  or  MS  C  approval. 

3.  Approve  full  funding  certification  for  MS  C. 

4.  Satisfactory  review  of  program  health. 
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Annex  1-F 

DON  Requirements/Acquisition  Gate  6  Pre-FRP  DR 
Exit  Criteria  Template 


1 .  Approval  to  proceed  to  FRP  DR  DAB  or  FRP  DR  approval . 

2.  Acceptance  of  the  disposition  of  the  major  system 
deficiencies  identified  during  IOT&E. 

3.  Approve  full  funding  certification  for  FRP. 

4.  Acknowledgement  of  CSB  recommended  capability  changes; 
approval  to  proceed  to  R3B/MROC,  or  CNO/CMC,  for  assessment  and 
Service  approval. 

5.  Satisfactory  review  of  program  health. 
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Annex  1-F 

DON  Requirements/Acquisition  Gate  6  Sustainment 

Exit  Criteria  Template 


1.  Concur  with  selected  recommendations  to  resolve  asset  and 
mission  readiness  issues  and  shortfalls. 

2.  Concur  with  TOC  reduction  opportunities. 

3.  Concur  with  risk  assessments. 

4.  Satisfactory  review  of  program  health. 
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Annex  1-G 

DON  Requirements/Acquisition  Gate  6  CSB 

Briefing  Content  Template 
[Attachment  1  of  ASN(RDSA)  memo  of  7  May  2008] 


PEO: 


Program  Name: 
ACAT  XX 


•  Requirements  Changes 


Impact  (Cost/Schd) 


•  Technical  Configuration  Chgs  Impact  (Cost/Schd) 


•  Safety  Changes 


Impact  (Cost/Schd) 


•  Potential  Descope  Options 


Estimated  Savings  ($) 


-  Vetted  with  Resource  Sponsor 
With  APB /Nunn -McCurdy  implications 

Technology  Insertion  Opportunities 
(Including  Technology  Refresh) 

-  Business  Case  Analysis  Backup  required 


•  Program  Manager  Recommendations 
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Chapter  2 

Statutory,  Regulatory,  and  Contract  Reporting  Information  and 

Milestone  Requirements 


References : 


(a) 

DoD  Directive  5000.01  of  12  May  2003 

(b) 

DoD  Instruction  5000.02  of  8  Dec  2008 

(c) 

SECNAVINST  5200. 38A 

(d) 

Assistant  Secretary  of  the  Navy  (Research, 

Development  and  Acquisition)  Memorandum,  DON 

Policy  on  Digital  Product/Technical  Data,  of 

Oct  2004 

(e) 

SECNAVINST  5000. 36A 

(f) 

SECNAVINST  5710. 25B 

(g) 

SECNAVINST  5510. 34A 

(h) 

SECNAVINST  4900.46B 

(i) 

DoD  Instruction  4630.8  of  30  Jun  2004 

(j) 

CJCSI  6212. 01E 

(k) 

DoD  Instruction  4650.01  of  9  Jan  2009 

(1) 

DoD  Directive  3222.3  of  8  Sep  2004 

(m) 

DoD  5200. 1-M,  Acquisition  Systems  Protection 

Program,  of  16  Mar  1994 

(n) 

DoD  Instruction  5200.39  of  16  Jul  2008 

(o) 

OPNAVINST  3432.1 

(p) 

DoD  Instruction  S-5230.28  of  2  Oct  2000 

(q) 

SECNAVINST  5239. 3B 

(r) 

OPNAVINST  5239. 1C 

(s) 

SECNAVINST  3052.2 

2 . 1  Program  Information 

In  support  of  SECNAV  and  ASN (RD&A) ,  each  Deputy  Assistant 
Secretary  of  the  Navy  (DASN)  for  their  cognizant  ACAT  I  and  II 
programs  should  review,  provide  input,  and  concur  with  appropriate 
acquisition  related  documents  (e.g..  Acquisition  Program  Baseline, 
Defense  Acquisition  Executive  Summary,  Selected  Acquisition  Report, 
Technology  Development  Strategy,  Acquisition  Strategy,  Test  and 
Evaluation  Master  Plan)  prior  to  the  documents  being  forwarded  to 
ASN (RD&A)  for  concurrence  or  approval . 

2.2  Exit  Criteria 


Exit  criteria  compliance  should  be  reported  via  the 
ASN (RD&A)  Information  System  Dashboard  for  all  ACAT  programs. 

Exit  criteria  compliance  for  ACAT  I  and  IA  programs  should  be 
included  in  the  Defense  Acquisition  Executive  Summary  (DAES)  that 
is  provided  via  ASN (RD&A)  Information  System  Dashboard  and  should 
be  included  in  the  Under  Secretary  of  Defense  for  Acquisition, 
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Technology  and  Logistics  (USD (AT&L) ) '  s  Defense  Acquisition 
Management  Information  Retrieval  (DAMIR)  System  and  Service 
Oriented  Architecture  (SOA)  System. 

2 . 3  Technology  Maturity 

Technology  Readiness  Levels  (TRLs)  listed  in  the  Defense 
Acquisition  Guidebook  and  in  the  ASD(R&E)  Technology  Readiness 
Assessment  Guidance  may  be  used  for  assessing  technology  maturity 
in  conducting  Technology  Readiness  Assessments  (TRAs)  for  all 
ACAT  programs.  TRLs  may  be  considered  by  the  MDA  in  determining 
the  maturity,  risk,  and  readiness  for  transitioning  new 
technologies  into  an  ACAT  program  at  milestone  B  and  into 
production  at  milestone  C.  Additional  information  about 
technology  transition  and  technology  transition  initiative  can  be 
accessed  at  http : / /www. acg.osd.mil/ott/tti/. 

Service  TRAs  are  required  for  all  ACAT  programs  at 
Milestones  B  and  C  pursuant  to  DoDI  5000.02  and  SECNAVINST 
5000. 2E,  table  E2T2 .  Service  TRAs  for  ACAT  ID  and  IC  programs 
will  be  submitted  to  Assistant  Secretary  of  Defense  for  Research 
and  Engineering  (ASD(R&E))  at  milestone  B  to  support  ASD(R&E)'s 
independent  review  and  assessment  of  technology  maturity  and  to 
determine  whether  a  program' s  technology  has  been  demonstrated  in 
a  relevant  environment  to  support  the  MDA' s  program  certification 
at  milestone  B  pursuant  to  section  2366b  of  title  10,  U.S.C. 

Additionally,  systems  engineering  technical  reviews  (for 
example  the  Alternative  Systems  Review  and  System  Requirements 
Review)  should  be  used  to  assess  technology  maturity  in  the 
context  of  system  requirements,  proposed  program  schedule,  and 
independent  estimate  of  program  costs.  These  reviews  can  be  a 
forum  for  subject  matter  experts  to  conduct  Developing  Activity 
(DA)  independent  technical  assessments  of  technology  maturity  as 
it  applies  to  the  overall  technical  and  programmatic  approach. 

The  ASD(R&E)  TRA  Guidance  in  the  first  paragraph  above 
should  be  used  as  a  guide  for  establishing  independent  TRA 
panels,  identifying  Critical  Technology  Elements  (CTEs) ,  planning 
and  conducting  TRAs,  and  developing  Technology  Maturation  Plans 
(TMPs)  for  CTEs  that  require  further  maturation.  The  ASD(R&E) 

TRA  Guidance  suggests  timelines  for  events  and  methods  for 
conducting  and  documenting  TRAs.  SYSCOMs  should  provide  subject 
matter  experts  for  membership  on  independent  TRA  panels,  and 
whenever  possible  a  standing  SYSCOM  TRA  Expert  Panel  Chair,  in 
support  of  Chief  of  Naval  Research  (CNR),  PEOs,  DRPMs,  and  PMs . 
CNR  will  provide  direction  for  the  conduct  of  Navy  TRAs,  and 
associated  processes  and  outputs. 

2 . 4  Technology  Development  and  Acquisition  Strategies 
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2.4.1  General  Considerations  for  a  Technology  Development 
Strategy  and  an  Acquisition  Strategy 

[ from  SNI  5000. 2E,  2.4.1,  fourth  subparagraph,  extract: 

PMs  for  all  DON  ACAT  programs  shall  develop  an  acquisition 
strategy  Implementing  a  total  systems  engineering  approach  per 
references  (a)  and  (b)  .  For  ACAT  IC,  IAC,  and  II  programs ,  the 
PM  shall  develop  the  acquisition  strategy  In  coordination  with 
the  Acquisition  Coordination  Team  (ACT) .  The  ACT  is  described  in 
chapter  1,  paragraph  1.3.2.  The  MDA  shall  approve  a  technology 
development  strategy  or  an  acquisition  strategy,  as  appropriate, 
prior  to  the  release  of  the  formal  solicitation  (RFP)  for  the 
respective  acquisition  phase.] 

Use  of  the  discretionary  procedures  provided  throughout 
this  DON  Acquisition  and  Capabilities  Guidebook  should  assist  PMs 
in  developing  technology  development  strategies  and  acquisition 
strategies  to  execute  ACAT  programs  that  are  well  defined  and 
carefully  structured  to  represent  a  judicious  balance  of  cost, 
schedule,  performance,  available  technology,  and  affordability 
constraints  prior  to  development,  production,  or  deployment 
approval . 

In  developing  a  technology  development  strategy  (TDS)  or 
an  acquisition  strategy  (AS) ,  PMs  should  be  aware  that  an 
evolutionary  acquisition  approach  is  the  preferred  strategy  for 
rapid  acquisition  of  mature  technology  for  the  user.  An 
evolutionary  approach  delivers  capability  in  increments, 
recognizing  up  front  the  need  for  future  capability  improvements. 
The  process  for  implementing  evolutionary  acquisition, 
incremental  development,  is  described  in  reference  (b) ,  enclosure 
2,  paragraph  2.  Use  the  PDUSD(ATSL)  revised  TDS  or  AS  Outline  at 
the  following  Web  site  http : / /www. acq. osd.mil/se/ do cs/PDUSD- 
Approved-TDS  AS  Qutline-04-20-2011.pdf  and  tailor  the  TDS  or  AS 
content  as  appropriate  to  satisfy  program  needs. 

2.4.2  Requirements/Capability  Needs 

2.4.3  Program  Structure 

[ from  SNI  5000. 2E,  2.4.3:  Each  Acquisition  Strategy 
shall  include  a  program  structure ,  the  purpose  of  which  is  to 
identify  in  a  top-level  schedule  the  major  program  elements 
such  as  program  decision  points,  acquisition  phases,  test 
phases,  contract  awards,  and  delivery  phases . ] 

Each  program  structure  should  also  include  program 
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elements  that  are  necessary  to  execute  a  successful  program, 
such  as  formal  solicitation  releases;  systems  engineering 
technical  reviews  including  preliminary  and  critical  design 
reviews;  engineering  development  model,  low-rate  initial 
production,  and  full-rate  production  deliveries;  developmental, 
live-fire,  and  operational  test  and  evaluation  phases;  and 
initial  and  full  operational  capability  dates.  These  program 
elements  are  contained  in  an  acquisition  strategy  proposed  by 
the  PM  and  approved  by  the  MDA.  See  references  (a)  and  (b)  and 
the  Defense  Acquisition  Guidebook  for  direction  and  guidance  on 
acquisition  strategy  program  elements  and  implementation 
requirements  for  all  DON  ACAT  programs. 

2.4.4  Risk 

[ from  SNI  5000. 2E,  2.4.4:  Plans  for  assessing  and 
mitigating  program  risk  shall  be  summarized  in  the  acquisition 
strategy.  PMs ,  utilizing  SYSCOM  engineering ,  cost ,  and  logistics 
technical  authority  expertise ,  shall  conduct  a  risk  assessment 
identifying  all  technical ,  cost,  schedule ,  and  performance  risks. 
In  conjunction  with  the  risk  assessment ,  plans  for  mitigating 
those  risks  shall  be  conducted  prior  to  each  milestone  decision 
and  the  full-rate  production  decision  review  (FRP  DR) .  PMs  for 
all  DON  programs  shall,  for  the  purpose  of  reducing  or  mitigating 
program  risk,  research  and  apply  applicable  technical  and 
management  lessons -learned  during  system  development , 
procurement,  and  modification.] 

System  engineering  technical  reviews  should  be  used  as 
an  integrated  technical  risk  assessment  tool.  Technical 
reviews  (such  as  the  System  Requirements  Review,  Preliminary 
Design  Review,  Critical  Design  Review,  System  Verification 
Review,  Production  Readiness  Review)  conducted  by 
independent  subject  matter  experts  with  the  program  team  can 
be  an  effective  method  of  ascertaining  technical  risk  at  key 
points  in  the  acquisition  life  cycle.  Technical  risks  and 
associated  mitigation  approaches  identified  at  these 
reviews  should  be  incorporated  into  the  program  plan  and 
budget . 


Environment,  Safety,  and  Occupational  Health  (ESOH)  and 
reliability  should  be  considered  in  the  overall  program  risk 
management  process.  An  ESOH  program  that  incorporates  the  system 
safety  methodology  pursuant  to  MIL-STD-882  current  version  should 
be  established  to  identify  ESOH  hazards  and  assess,  verify, 
validate,  and  accept  the  associated  ESOH  risks.  Additional 
guidance  on  risk  management  and  system  safety  implementation  may 
be  found  in  the  Defense  Acquisition  Guidebook. 
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2. 4. 4.1  Interoperability  and  Integration  Risk 

[ from  SNI  5000. 2E,  2. 4. 4.1,  last  subpara:  For  ACAT  I,  IA, 
and  II  programs  and  applicable  ACAT  III  and  IV  programs  that  are 
designated  by  ASN (RD&A)  for  integration  and  interoperability 
special  interest,  risk  assessment  planning  shall  be  coordinated 
with  DASN (RDT&E)  chief  systems  engineer  (CHSENG)  6  months  prior 
to  program  decision  briefings .  Developed  risk  assessments  and 
mitigation  plans  for  such  programs  shall  be  submitted  to 
DASN (RDT&E)  CHSENG  no  later  than  30  calendar  days  prior  to 
program  decision  briefings.  DASN (RDT&E)  CHSENG  shall  advise 
ASN (RD&A)  and  the  PM  of  the  adequacy  of  the  integration  and 
interoperability  risk  assessment  and  risk  mitigation  plan.] 

DASN (RDT&E)  CHSENG  is  available  to  assist  the  PM  in  the 
identification  of  integration  and  interoperability  risks  or  in 
the  use  of  interoperability  and  integration  risk  assessment 
tools.  ASN (RD&A)  publication  NAVSO  P-3686,  "Top  Eleven  Ways  to 
Manage  Technical  Risk, "  should  be  used  as  a  guideline  for 
establishing  a  technical  risk  management  program.  Several  risk 
assessment  tools  are  available  in  the  Defense  Acquisition 
Guidebook  to  assist  in  the  identification  of  risks. 

Additionally,  systems  engineering  technical  reviews  should  be 
used  as  an  integrated  technical  risk  assessment  tool. 

2.4.5  Program  Management 

2. 4. 5.1  Integrated  Digital  Environment  (IDE) 

Engineering  and  logistics  technical  data  for  new  systems, 
modeling  and  simulation,  and  applicable  engineering  and  logistics 
technical  data  from  legacy  systems  which  interface  with  new 
systems;  should  be  acquired  and  developed  in  digital  electronic 
form  to  perform  life-cycle  support  using  digital  operations  per 
references  (c) ,  (d) ,  and  (e) .  The  DON  policy  on  digital 

logistics  technical  data,  reference  (d) ,  provides  guidance  on 
acquisition  and  conversion  of  logistics  technical  data  to  digital 
form.  See  the  Defense  Acquisition  Guidebook  for  implementation 
guidance  for  all  DON  programs. 

2. 4. 5. 2  Technical  Representatives  at  Contractor  Facilities 

See  the  Defense  Acquisition  Guidebook  for  implementation 
guidance  for  all  DON  ACAT  programs. 

2. 4. 5. 3  Government  Property  in  the  Possession  of 
Contractors  (GPPC) 


PMs  who  have  or  use  GPPC  should  have  a  process  in  place  to 
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ensure  the  continued  management  emphasis  on  reducing  GPPC  and  the 
preventing  of  any  unnecessary  additions  to  GPPC.  See  the  Defense 
Acquisition  Guidebook  for  GPPC  monitoring  guidance  for  all  DON 
programs . 

2. 4. 5. 4  Planning  for  Simulation-Based  Acquisition  (SBA) 
and  Modeling  and  Simulation  (M&S) 

Reference  (c)  provides  guidance  for  DON  modeling  and 
simulation  management.  See  the  Defense  Acquisition  Guidebook  for 
implementation  guidance  for  all  DON  ACAT  programs. 

2.4.6  Design  Considerations  Affecting  the  Acquisition 
Strategy 

2. 4. 6.1  Open  Architecture 

2. 4. 6. 2  Interoperability  and  Integration 

[from  SNI  5000.2E,  2. 4.  6. 2:  For  programs  that  are  part  of 
a  SoS  or  FoS ,  interoperability  and  integration  shall  be  a  major 
consideration  during  all  program  phases  per  reference  (g) .  The 
acquisition  strategy  of  all  programs  shall  implement 
interoperability  processes ,  procedures ,  and  tools ,  per  reference 
(h) ,  as  the  foundation  for  information  interoperability . ] 

Interoperability  and  integration  risks  should  be 
identified  using  the  guidance  in  the  Defense  Acquisition 
Guidebook.  Interoperability  and  integration  include 
considerations  such  as  physical/mechanical  interchangeability  and 
"form,  fit,  and  function, "  as  well  as  the  exchange  of  data  and 
services.  For  information  on  interoperability  as  addressed  in 
the  Net-Centric  Data  Strategy,  see  DoD  Directive  8320.02  and 
Defense  Acquisition  Guidebook,  chapter  7,  Acquiring  Information 
Technology  and  National  Security  Systems.  Also  see  ASD(NII)/DOD 
CIO  memorandum  9  May  2003,  DoD  Net-Centric  Data  Strategy. 

2. 4. 6. 2.1  Integrated  Architecture 

2. 4. 6. 3  Aviation  and  Ship  Critical  Safety  Items 

Aviation  and  ship  critical  safety  items  (CSIs)  are  parts, 
assemblies,  installations,  launching  or  recovery  equipment,  or 
support  equipment  containing  a  critical  characteristic  whose 
failure,  malfunction,  or  absence  may  cause  a  catastrophic  or 
critical  failure  resulting  in  loss  or  serious  damage  to  the 
aircraft,  ship,  or  weapon  system,  unacceptable  risk  of  personal 
injury  or  loss  of  life,  or  an  uncommanded  engine  shutdown 
resulting  in  an  unsafe  condition. 
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2. 4. 6. 4  Information  Assurance 

[from  SNI  5000. 2E,  para  2. 4.  6. 4  extract:  Information 
assurance  (IA)  requirements  shall  be  identified  and  included  in 
the  design ,  acquisition ,  installation ,  operation,  upgrade,  and 
replacement  of  all  DON  information  systems  per  section  2224  of 
title  10,  U.S.C.,  Office  of  Management  and  Budget  Circular  A-130, 
and  reference  (b)  .  ] 

PMs  should  ensure  the  acquisition  strategy  provides  for 
compliance  with  the  procedures  regarding  IA.  PMs  should 
summarize  in  the  acquisition  strategy  the  technical,  schedule, 
cost,  and  funding  issues  associated  with  executing  requirements 
for  IA,  and  maintain  a  plan  to  resolve  any  issues  that  arise. 

The  IA  strategy  should  define  the  planning  approach  the  PM  will 
take  during  the  program  to  ensure  that  IA  requirements  are 
addressed  early  on  and  Clinger-Cohen  Act  requirements  for  IA  are 
captured.  The  IA  strategy  will  continue  to  evolve  during 
development  through  test  and  evaluation,  so  that  by  Milestone  C 
it  contains  sufficient  detail  to  define  how  the  program  will 
address  the  fielding  and  support  requirements  that  meet  material 
readiness  and  performance  objectives. 

2. 4. 6. 5  Standardization  and  Commonality 

2. 4. 6. 6  Data  Management  and  Technical  Data  Rights 

2. 4. 6. 7  Protection  of  Critical  Program  Information  and 
Anti-Tamper  (AT)  Measures 

See  this  Guidebook,  paragraphs  2.8.1  and  2. 8. 1.1  for  AT 
guidance . 

2.4.7  Support  Strategy 

[ from  SNI  5000. 2E,  2.4.7,  first  subparagraph:  Support 
planning  shall  show  a  balance  between  program  resources  and 
schedule  so  that  systems  are  acquired,  designed,  and  introduced 
efficiently  to  meet  CDD  and  CPD  and  APB  performance  design 
criteria  thresholds.  The  PM  as  the  life-cycle  manager, 
designated  under  the  tenets  of  total  life-cycle  systems 
management  (TLCSM) ,  shall  document  the  product  support  strategy 
in  the  LCSP .  The  Logistics  Requirements  and  Funding  Summary 
(LRFS)  is  a  required  adjunct  of  the  LCSP  and  the  program's 
basis  for  relating  LCSP  execution  to  programmatic  resources . 
Performance  based  logistics  (PBL)  is  the  preferred  support 
strategy  and  method  of  providing  weapon  system  logistics 
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support.  A  comprehensive  business  case  analysis ,  derived  in 
large  part  from  related  and  fielded  systems'  sustainment 
performance  efficiency  and  the  life-cycle  cost  affordability  of 
that  performance ,  will  be  the  basis  for  selecting  a  support 
strategy  and  reflecting  the  associated  tradeoffs  (e.g. ,  among 
all  systems  technical  performance ,  infrastructure 
capabilities ,  and  organic  and  commercial  business 
considerations ) .  A  program  level  PBL  implementation  plan  shall 
be  developed  for  all  programs  using  a  PBL  support  strategy . ] 

Support  planning,  and  its  execution,  forms  the  basis  for 
fleet  or  Marine  Corps  forces  introduction  and  deployment 
recommendations  and  decisions.  Reliability,  availability,  and 
maintainability  are  critical  considerations  in  the  development 
of  the  support  strategy.  See  the  Defense  Acquisition  Guidebook 
for  implementation  guidance  for  all  DON  ACAT  programs. 

The  PM,  in  coordination  with  military  service  logistics 
commands,  is  the  Total  Life-Cycle  Manager  (TLCM) .  This 
includes  full  life-cycle  product  support  execution  and  resource 
planning  responsibilities.  The  overall  product  support 
strategy,  documented  in  the  LCSP,  should  include  life-cycle 
support  planning  and  should  address  actions  to  assure 
sustainment  and  to  continually  improve  product  affordability 
for  programs  in  initial  procurement,  re-procurement,  and  post¬ 
production  support. 

2. 4. 7.1  Human  Systems  Integration  (HSI) 

The  summary  of  HSI  planning  included  in  a  systems 
engineering  plan  (SEP)  should  illustrate  how  the  PM  intends  to 
effectively  meet  the  HSI  requirements  in  the  DOD  5000  series  and 
SECNAVINST  5000. 2E.  The  Navy's  established  Enterprise  approach 
to  HSI  is  called  Systems  Engineering,  Acquisition  and  Personnel 
Integration  (SEAPRINT) . 

The  following  information  should  be  considered  in 
developing  the  HSI  section  of  a  SEP.  However,  if  the  MDA  and  the 
PM  elect  to  require  a  separate  HSI  Plan  (see  paragraph  2.9.1  of 
this  guidebook) ,  this  information  should  be  included  in  that 
document;  the  SEP  can  then  refer  to  the  HSI  Plan. 

a.  Provide  a  summary  overview  of  the  HSI  strategy, 
addressing  HSI  risk  assessment  and  reduction,  application  of 
technology  in  the  achievement  of  HSI  objectives,  establishment  of 
HSI  priorities,  and  a  description  of  the  process  to  be 
implemented  to  ensure  HSI  objectives  are  met. 

b.  Explain,  with  rationale,  any  tailoring  of  required  HSI 
activities . 
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c.  Provide  a  complete  list  of  all  commands  and  activities 
involved  with  the  HSI  effort;  explain  the  organizational 
structure  of  the  program  (including  industry  partners)  and 
describe  the  role  of  the  HSI  team  within  that  structure. 

d.  Describe  how  HSI  will  be  integrated  with  all 
acquisition  logistics  support  (ALS)  analyses  and  activities. 

e.  Summarize  HSI  constraints  and  results  of  the  HSI 
analyses  and  trade-offs. 

f.  Describe  prior  decisions,  assumptions,  mandated 
constraints  and  information  pertaining  to  HSI. 

g.  Describe  the  total  systems  approach  (hardware, 
software,  human) ;  describe  how  the  performance  characteristics 
for  humans  were  integrated  into  the  system. 

h.  Develop  a  tailored  list  of  all  HSI  activities  by 
milestone;  show  the  POA&M  for  HSI  activities  overlaid  with  the 
program  schedule;  highlight  any  inconsistencies  or  conflicts. 

i.  Describe  how  HSI  requirements  contribute  to  mission 
capability,  material  readiness,  force  structure,  affordability, 
performance  effectiveness,  and  achievement  of  wartime  operational 
ob j  ectives . 

j .  Describe  the  total  system  performance  goals  that 
require  HSI-related  design  interface  and  support  analysis. 

k.  Identify  key  issues  that  have  HSI  implications, 
including  constraints  established  in  the  Initial  Capabilities 
Document  (ICD);  include  major  design,  material  readiness,  test 
and  evaluation,  and  affordability  issues. 

l.  Summarize  how  the  system  addresses  the  cognitive, 
sensory,  and  physical  needs  of  the  human  operators.  Summarize 
the  approach  for  human-centered  design  initiatives. 

m.  Identify  the  HSI  analyses  to  be  conducted  and  their 
effects  on  managing  HSI  risks. 

2. 4. 7. 2  Environment,  Safety,  and  Occupational  Health 
(ESOH)  Considerations 


ESOH  planning  and  execution  is  integral  to  the  systems 
engineering  process  for  all  developmental  and  sustaining 
activities.  As  part  of  the  program's  overall  risk  reduction,  the 
program  manager  should  eliminate  ESOH  hazards,  where  possible. 
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and  manage  their  associated  risks  where  hazards  cannot  be 
eliminated . 

The  programmatic  environment,  safety  and  occupational 
health  evaluation  (PESHE)  is  an  ongoing  evaluation  of  mitigation 
effectiveness  and  includes  the  identification,  assessment, 
mitigation,  and  acceptance  of  ESOH  risks  and  a  National 
Environmental  Policy  Act  (NEPA)  and  Executive  Order  (E.O.)  12114 
Compliance  Schedule.  According  to  PDUSD(AT&L)  Memorandum, 
Document  Streamlining-Program  Strategies  and  Systems  Engineering 
Plan,  of  20  Apr  2011,  the  PESHE  and  NEPA/EO  12114  Compliance 
Schedule  are  no  longer  part  of  the  Acquisition  Strategy,  but  are 
stand-alone  documents.  PESHE  and  NEPA  compliance  design 
considerations  are  captured  in  the  Systems  Engineering  Plan 
(SEP) .  Program  Managers  should  provide  "hotlinks"  in  the  SEP 
that  will  permit  easy  access  to  the  PESHE  and  NEPA  Compliance 
Schedule . 

2. 4. 7. 3  Demilitarization  and  Disposal  Planning 

As  part  of  the  program  manager' s  Total  Life  Cycle  Systems 
Management  responsibilities,  the  PM  should  consider  materiel 
demilitarization  and  disposal  during  systems  engineering.  The 
environmental  risk  and  cost  associated  with  decontamination, 
decommissioning,  demilitarization,  and  disposal  of  the  system 
should  be  minimized  and  all  hazardous  materials  used  on  the 
system  should  be  identified,  quantified,  and  mapped  by  location 
in  the  system. 

2. 4. 7. 4  Post  Deployment  Performance  Review 

[from  SNI  5000. 2E,  2. 4.  7. 4:  In-service  reviews  (ISRs)  may 
be  conducted  periodically  until  the  end  of  the  life-cycle  is 
reached. ] 

The  primary  focus  of  statutory  Post  Deployment  Performance 
Reviews  (PDPRs) /Post  Implementation  Reviews  (PIRs)  conducted  as 
part  of  ISRs  is  on  how  well  an  ACAT  program  is  meeting  its 
mission,  performance,  management,  financial,  and  technical  goals. 
Senior  management  for  ACAT  IA  programs  will  review  the  PDPR/PIR 
reports  for  inputs  to  IT  investment  decisions.  Guidance  to 
assist  organizations  in  conducting  PDPRs/PIRs  of  IT  investments 
as  required  by  the  Clinger-Cohen  Act  of  1996  is  provided  in  the 
DON  IT  Investment  Evaluation  Handbook,  which  can  be  found  on  the 
DON  Chief  Information  Officer  (CIO)  website  at 

http : / /www. doncio . navy.mil/ ContentView. aspx?id=3059 .  PDPRs/PIRs 
should  consider  safety  and  survivability  as  well  as  the 
effectiveness  of  the  implementation  of  human  systems  integration 
strategies.  See  the  Defense  Acquisition  Guidebook  for  PDPR/PIR 
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implementation  guidance  for  all  applicable  programs. 

2. 4. 7. 5  Program  Protection  Planning 

2. 4. 7. 6  Product  Support 

2. 4. 7. 6.1  Product  Support  Management  Planning 

Planning  for  a  performance  based  logistics  (PBL)  strategy 
should  be  rationalized  by  support  analysis,  baseline  assessment, 
and  the  establishment  of  support  performance  metrics.  PBL 
decisions  should  also  be  based  on  the  operational  environment  and 
the  logistics  infrastructure's  ability  to  support  non-PBL  defense 
programs.  PBL  requirements  should  be  invoked  with  contractors 
where  appropriate. 

A  DoD  guide  for  the  development  of  a  PBL  strategy  for 
product  support  of  weapon  systems  titled  "A  Program  Manager' s 
Guide  to  Buying  Performance"  of  6  Nov  01  is  available  on  the 
ASN (RD&A)  web  page  which  can  be  found  at 

http : / /www. acquisition . navy.mil/ .  The  foregoing  guide  is 
retained  for  information,  but  it  has  been  superseded  by 
"Performance  Based  Logistics:  A  Program  Manager's  Product 
Support  Guide"  of  20  Mar  05  that  is  available  on  the  Defense 
Acquisition  University  (DAU)  Defense  Acquisition  Portal  (DAP) 
Acquisition  Community  Connection  (ACC) . 

DON  PBL  guidance  is  provided  in  DON  PBL  Guidance  Document 
of  27  Jan  2003  which  was  supplemented  by  ASN (RD&A)  memorandum  of 
6  Nov  2007  Department  of  the  Navy  Guide  to  Developing  Performance 
Based  Logistics  Business  Case  Analyses  (P07-006) . 


PBL  contract  categories,  review,  and  clearance  authority 
are  provided  below  in  Table  E2T1. 
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Table  E2T1  PBL  Contract  Review  and  Clearance  Authority 

PBL 

Contract 

Category 

PBL  Contract 

Total  Estimated 
Dollar  Value 

PBL  Contract 
Requirements 
Review 

PBL  Contract 

Review 

PBL  Contract 

Clearance 

Authority 

ASN (RD&A) 

Special 

Interest 

As  designated  by 

ASN (RD&A) 

Budget 

Submitting 

Office 

DASN (AP) 

Head  of  the 
Contracting 
Activity  (HCA) 

ASN (RD&A) 

Cat  I 

>  $250  million  (see 

Note  1  for  2:  $1 
billion  (B) ) 

Budget 

Submitting 

Office 

DASN (AP) 

HCA 

ASN (RD&A)  >  $ IB 
ASN (RD&A),  or 
designee  <  $1B 

Cat  II 

>  $10  million  <  $250 
million 

Requiring 

Activity 

HCA 

PEO,  DRPM,  PM 
or  HCA 

Cat  III 

>  the  simplified 
acquisition  threshold 
<  $10  million 

Requiring 

Activity 

Contracting 

Officer 

Contracting 

Officer 

NOTES : 

1 .  Proposed  PBL  contracts  with  a  total  estimated  dollar  value  equal  to  or  greater  than  1  billion 
dollars  (base  year  and  options)  shall  be  reviewed  and  approved  by  ASN (RD&A) . 

2.  Dollar  amounts  are  in  Fiscal  Year  2006  constant  year  dollars. 

3.  Acquisition  of  PBL  support  that  is  part  of  a  weapon  system  acquisition  program  or  Automated 
Information  System  (AIS)  acquisition  program  managed  per  references  (b)  and  (c)  shall  be  reviewed 
and  approved  as  part  of  that  program' s  overall  Acquisition  Strategy,  unless  the  MDA  determines 
that  the  PBL  support  shall  be  reviewed  and  approved  under  a  separate  PBL  Acquisition  Strategy. 

4.  Related  task  orders  within  an  ordering  vehicle  shall  be  viewed  as  one  effort  for  the  purpose 
of  determining  the  appropriate  thresholds. 


2. 4. 7. 7  Planning  for  Parts  and  Materials  Obsolescence 

Support  planning  should  include  a  process  to  resolve 
problems  created  by  parts  and/or  materials  obsolescence  and 
reduce  or  eliminate  any  negative  impacts.  Such  planning 
should  proactively  consider  the  impact  of  obsolescence  on  the 
acquisition  life  cycle  by  anticipating  potential  obsolescence 
and  taking  appropriate  logistics,  acquisition,  and  budgeting 
steps  to  prevent  obsolescence  from  adversely  affecting 
material  readiness  or  total  ownership  cost.  As  a  necessary 
adjunct  to  this  element  of  support  planning,  the  process 
should  ensure  that  obsolescence  mitigation  information  is 
effectively  communicated  and  exchanged  within  DON,  with  other 
Government  organizations,  and  with  industry  through  maximum 
use  of  alerts  and  the  Government-Industry  Data  Exchange 
Program  (GIDEP) . 

2.4.8  Business  Strategy 

2 . 4 . 8 . 1  International  Cooperation* 

[  from  SNI  5000. 2E,  2. 4. 8.1:  PMs  for  DON  ACAT  programs 
shall  consult  with  the  Navy  International  Programs  Office  (IPO) 
during  development  of  the  international  element  of  the  program's 
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acquisition  strategy  to  obtain: 

a.  Relevant  international  programs  information,]  such  as 
research,  development,  and  acquisition  international  agreements 
that  are  existing,  proposed,  or  under  consideration  by  allies  and 
friendly  nations;  anti-tamper  policies;  and  data  exchange 
agreements  with  allied  and  friendly  nations. 

b.  [ from  SNI  5000. 2E ,  2. 4. 8.1:  ASN (RD&A)  policy  and 
procedures  regarding  development ,  review,  and  approval  of 
international  armaments  cooperation  programs ,]  as  established  by 
reference  (f) . 

c.  [ from  SNI  5000.2E,  2. 4. 8.1:  DON  technology  transfer 
policy]  established  by  references  (g)  and  (h)  under  the  policies 
of  the  Secretary  of  Defense  as  recommended  by  the  National 
Disclosure  Policy  Committee  (NDPC) . 

See  the  Defense  Acquisition  Guidebook  for  implementation 
guidance  for  all  DON  ACAT  programs. 

*This  paragraph  is  not  normally  applicable  to  IT  programs. 

2. 4. 8. 1.1  International  Cooperative  Strategy 

The  business  strategy  should  identify  similar 
programs/projects  under  development  or  in  production  by  an  ally. 
The  acquisition  strategy  assesses  whether  a  similar 
program/project  could  satisfy  U.S.  requirements,  and  if  so, 
recommend  designating  the  program  an  international  cooperative 
program.  DON  PMs  and/or  PEOs  should  consult  with  the  Navy  IPO  in 
order  to  ensure  their  programs  are  consistent  with  Navy 
International  Programs  Office  campaign  plans  for  sales  to  allied 
and  friendly  nations. 

2. 4. 8. 1.2  International  Interoperability 

2. 4. 8. 2  Competition 

PMs  should  consider  acquiring  rights  in  technical  data  and 
computer  software  sufficient  to  permit  competing  follow-on 
acquisitions . 

2. 4. 8. 3  Warranties 

The  PM  should  examine  the  value  of  warranties  and  pursue 
such  warranties  when  appropriate  and  cost-effective.  When 
appropriate,  the  PM  should  incorporate  warranty  requirements  in 
the  contractual  language  per  Federal  Acquisition  Regulation 
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Subpart  46.7  and  Defense  Federal  Acquisition  Regulation 
Supplement  paragraph  246.7.  See  the  Defense  Acquisition 
Guidebook  for  implementation  guidance  for  all  DON  ACAT  programs. 

2 . 5  Intelligence  Support 

2 . 6  Information  and  Command,  Control,  Communications,  Computers, 
and  Intelligence  (C4I)  Support 

[from  SNI  5000. 2E,  2.6,  first  subparagraph,  extract:  PMs 
shall  develop  information  support  plans  (ISPs)  for  those  IT, 
including  NSS,  ACAT,  non  - ACAT ,  and  fielded  systems  that  connect 
in  any  way  to  the  communications  and  information  infrastructure. 
ISPs  shall  be  maintained  and  updated  over  the  life-cycle  of  the 
system.  ] 

See  the  Defense  Acquisition  Guidebook  for  Information 
Support  Plan  implementation  guidance  and  formats  for  IT, 
including  NSS,  ACAT  I,  IA,  II,  III,  and  IV  programs  when  they 
connect  in  any  way  to  the  communications  and  information 
infrastructure . 

ISPs  for  IT,  including  NSS,  ACAT  I  and  IA  programs,  and 
DoD  CIO  special  interest  IT,  including  NSS,  programs  are  to  be 
entered  into  the  Joint  C4I  Program  Assessment  Tool-Empowered 
(JCPAT-E)  for  review.  After  approval,  ISPs  for  all  IT,  including 
NSS,  programs  are  to  be  entered  into  the  JCPAT-E  repository  for 
retention  per  references  (i)  and  (j) . 

2 . 7  Electromagnetic  Environmental  Effects  (E3)  and 
Electromagnetic  Spectrum  Supportability 

E3  control  is  concerned  with  design  and  engineering  to 
minimize  the  impact  of  the  electromagnetic  environment  on 
equipment,  systems,  and  platforms.  E3  control  applies  to  the 
electromagnetic  interactions  of  both  spectrum-dependent  and  non- 
spectrum-dependent  objects  within  the  operational  environment. 
Examples  of  non-spectrum-dependent  objects  that  could  be  affected 
by  the  electromagnetic  environment  are  ordnance,  personnel,  and 
fuels.  The  increased  dependency  on  and  competition  for  portions 
of  the  electromagnetic  spectrum  have  amplified  the  likelihood  of 
adverse  interactions  among  sensors,  networks,  communications,  and 
weapon  systems. 

The  objective  of  establishing  E3  control  requirements  in 
the  acquisition  process  is  to  ensure  that  DON  equipment, 
subsystems,  and  systems  are  designed  to  be  self-compatible  and 
operate  compatibly  in  the  operational  electromagnetic 
environment.  To  be  effective,  the  program  manager  should 
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establish  E3  control  requirements  early  in  the  acquisition 
process  to  ensure  compatibility  with  co-located  equipment, 
subsystems,  and  systems,  and  with  the  applicable  external 
electromaqnetic  environment. 

National,  international,  and  DoD  policies  and  procedures 
for  the  management  and  use  of  the  electromagnetic  spectrum 
require  program  managers  developing  spectrum-dependent 
systems/equipment  to  consider  spectrum  supportability 
requirements  and  E3  control  early  in  the  development  process. 
Given  the  complex  environment  (both  physical  and  political)  in 
which  DoD  forces  operate,  and  the  potential  for  worldwide  use  of 
capabilities  procured  for  DoD,  early  and  thorough  consideration 
is  vitally  important.  The  spectrum  supportability  process 
includes  the  following: 

a.  The  spectrum-dependent  system/equipment  being  acquired 
is  designed  to  operate  within  the  proper  portion  of  the 
electromagnetic  spectrum; 

b.  Permission  has  been  (or  can  be)  obtained  from 
designated  authorities  of  sovereign  ("host")  nations  (including 
the  United  States  and  Protectorates)  to  use  that  equipment  within 
their  respective  borders;  and 

c.  The  newly  acquired  equipment  can  operate  compatibly 
with  other  spectrum  dependent  equipment  already  in  the  intended 
operational  environment  (electromagnetic  compatibility) . 

References  (k)  and  (1)  implement  E3  and  spectrum 
management/spectrum  supportability  within  the  Navy  and  Marine 
Corps,  respectively.  See  reference  (b) ,  enclosure  4,  for 
implementation  requirements  for  all  DON  ACAT  programs.  Expanded 
guidance  is  available  from  the  Defense  Acquisition  Guidebook. 

2.7.1  Electromagnetic  Environmental  Effects  (E3) 

Achievement  of  compatibility  in  the  operational 
electromagnetic  environment  is  the  paramount  objective  of  the 
Navy  E3  Program.  The  Navy  E3  program's  primary  goal  is  to 
enhance  force  performance  by  institutionalizing  the  prediction 
and  design  of  the  operational  Navy  electromagnetic  environment 
(EME) ,  and  the  correction,  prevention,  and  control  of  degradation 
to  warfighting  capability  caused  by  the  interaction  of  the  EME 
with  Navy  equipment,  systems,  platforms,  and  personnel.  E3 
design  requirements  for  all  DON  communications  and  electronics 
(C-E)  systems  and  equipment  should  be  identified  in  all  necessary 
acquisition  documents  during  the  DON  acquisition  process  and 
integrated  into  all  developmental  and  operational  tests  per 
references  (k)  and  (1) .  E3  design  requirements  should  apply  to 
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all  phases  of  the  acquisition  process  and  should  be  implemented 
as  early  as  possible  in  the  conceptual,  design,  acquisition,  and 
operational  phases  of  all  equipment,  systems  and  platforms.  E3 
control  should  be  planned  for  and  incorporated  in  all  Navy 
equipment,  systems  and  platforms  including  commercial  items  and 
non-developmental  items. 

All  munitions  and  electric  or  electronic  systems  and 
equipment  will  be  designed  or  procured  to  be  mutually  compatible 
with  other  electrical  or  electronic  equipment  within  their 
expected  operational  environment.  This  encompasses 
electromagnetic  compatibility  (EMC) /electromagnetic  interference 
(EMI);  electromagnetic  vulnerability  (EMV) ;  electromagnetic  pulse 
(EMP) ;  electrostatic  discharge  (ESD) ;  hazards  of  electromagnetic 
radiation  to  personnel  (HERP) ,  to  ordnance  (HERO) ,  and  to  fuel 
(volatile  materials)  (HERF) ;  and  natural  phenomena  effects  of 
lightning  and  precipitation  static  (P-static) . 

Key  Review  Actions  by  Program  Managers ; 

a.  Define,  and  update  as  necessary,  applicable 
electromagnetic  environments  where  systems/equipment  are/is 
intended  to  operate; 

b.  Establish  E3  control  requirements,  with  special 
emphasis  on  mutual  compatibility  and  HERO  guidance; 

c.  Define  E3  programmatic  requirements  to  include 
analyses,  modeling  and  simulation,  and  test  and  evaluation;  and 

d.  Ensure  that  E3  developmental  test  and  evaluation/ 
operational  test  and  evaluation  requirements  and  spectrum 
management  planning  and  analyses  are  addressed  in  the  Test  and 
Evaluation  Master  Plan,  and  that  resources  are  identified  to 
support  these  activities. 

2.7.2  Electromagnetic  Spectrum  Certification  and 
Supportability 

Spectrum  certification  effects  spectrum  supportability. 

The  program  manager  should  initiate  the  spectrum  certification 
(DD  Form  1494  Application  for  Equipment  Frequency  Allocation) 
process  prior  to  Milestone  B  to  ensure  spectrum  supportability 
early  in  the  development  cycle. 

Spectrum  certification  is  the  statement  of  adequacy 
received  from  authorities  of  sovereign  nations  after  their  review 
of  the  technical  characteristics  of  spectrum  dependent  equipment 
or  systems  regarding  compliance  with  their  national  spectrum 
management  policy,  allocations,  regulations,  and  technical 
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standards.  The  purpose  of  spectrum  certification  is  to: 

a.  Obtain  authorization  from  the  National 
Telecommunications  and  Information  Administration  to  develop  or 
procure  items  that  use  a  defined  frequency  band(s)  or  specified 
frequencies  to  accommodate  a  specific  electronic  function (s); 

b.  Ensure  compliance  with  national  policies  and 
allocation  tables  which  provide  order  in  the  use  of  the  radio 
frequency  spectrum;  and 

c.  Ensure  spectrum  availability  to  support  the  item  in 
its  intended  operational  environment. 

The  spectrum  certification  process  is  used  to  receive  an 
approved  electromagnetic  frequency  allocation  and  Host  Nation 
Agreement  if  the  system  is  to  operate  in  international 
electromagnetic  environments.  A  DP  Form  1494,  Application  for 
Equipment  Frequency  Allocation,  is  required  for  spectrum 
certification  by  the  National  Telecommunication  and  Information 
Administration  (NTIA)  for  all  spectrum  dependent  systems  and  all 
systems  employing  satellite  techniques  (47  U.S.C.  Sections  901- 
904).  Spectrum  dependent  systems  are  those  electronic  systems, 
subsystems,  and  devices  and/or  equipment  that  depend  on  the  use 
of  the  electromagnetic  spectrum  for  the  acquisition  or 
acceptance,  processing,  storage,  display,  analysis,  protection, 
disposition,  and  transfer  of  information. 

a.  The  DD  Form  1494  documents  the  spectrum-related 
technical  and  performance  characteristics  of  an  acquisition  item 
to  ensure  compliance  with  the  applicable  DoD,  individual 
national,  both  U.S.  and  foreign,  and  international  spectrum 
management  policies  and  regulations. 

b.  The  DD  Form  1494  is  routed  through  command  channels  to 
the  sponsoring  Military  Department  Frequency  Management  Office: 
the  U.S.  Army  Spectrum  Management  Office,  the  Navy-Marine  Corps 
Spectrum  Center,  or  the  Air  Force  Frequency  Management  Agency. 

(1)  The  Military  Department  representative  then 
submits  the  form  to  the  Spectrum  Planning  Subcommittee  of  the 
Interdepartmental  Radio  Advisory  Committee  under  the  NTIA;  and 

(2)  The  Service  Frequency  Management  Office  (FMO) 
submits  the  form  to  the  Equipment  Spectrum  Guidance  Permanent 
Working  Group  (ESG  PWG)  under  the  Frequency  Panel  of  the  Joint 
Staff  MCEB. 

Requirements  for  foreign  spectrum  support  will  be 
forwarded  to  the  MCEB  ESG  PWG  for  coordination  with  host  nations 
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where  deployment  of  the  system  or  equipment  is  anticipated. 
Spectrum  certification  updates  should  be  prepared  at  each 
subsequent  acquisition  milestone.  The  Navy  and  Marine  Corps 
Spectrum  Center  can  assist  PMs  with  the  spectrum  certification 
process . 


2. 7. 2.1  Electromagnetic  Spectrum  Certification  Compliance 

As  part  of  the  milestone  review  process,  the  MDA  should 
ensure  that  electromagnetic  spectrum  supportability  has  been 
approved.  Additionally,  PMs  should  complete  spectrum 
supportability  assessment  factors  shown  in  Table  E2T4  of  chapter 
2  of  SECNAVINST  5000. 2E  prior  to  award  of  a  contract  for 
acquisition  of  any  system  that  employs  the  electromagnetic 
spectrum.  The  applicable  program  information  shown  in  Table 
E3T4  are  examples  of  the  most  likely  references  for  the  required 
information.  If  the  PM  deems  other  references  more  appropriate, 
they  may  be  used  in  addition  to  or  instead  of  those  cited. 

2. 7. 2. 2  Electromagnetic  Spectrum  Supportability 
2 . 8  Technology  Protection 

[ from  SNI  5000. 2E,  2.8:  Each  DON  program  that  contains 
critical  program  information  (CPI)  shall  prepare  a  program 
protection  plan  (PPP)  per  references  (n)  and  (o) .  PPPs  shall 
address  effective  CPI  protection  measures  to  include  a  PM- 
approved  classified  anti- tamper  (AT)  annex  that  has  Naval  Air 
Systems  Command  (NAVAIRSYSCOM) ' s  technical  concurrence  as  DON'S 
AT  technical  authority.  DASN (RDT&E)  CHSENG  is  the  DON  point-of- 
contact  for  DoD  and  DON  AT  policy  matters  and  for  working  with 
the  DoD  AT  executive  agent. 

CNO  (N2/N6  and  N3/N5)  shall  provide  operations  security 
(OPSEC)  and  OPSEC  enhancement  planning  guidance  during  ICD 
review.  CNO  (N2/N6  and  N3/N5)  shall  coordinate  guidance 
preparation  and  shall  assist  the  PM' s  staff  in  subsequent  OPSEC 
and  program  protection  planning  involving  critical  program 
information.  Detailed  policy  and  procedures  are  found  in 
reference  (p)  .  ] 

The  PPP  should  encompass  security,  acquisition  systems 
protection,  systems  security  engineering,  counterintelligence, 
and  operations  security  (SASCO)  requirements.  SASCO  requirements 
are  contained  in  reference  (n) .  A  format  for  a  PPP  is  provided 
in  PDUSD(AT&L)  memorandum.  Document  Streamlining  --  Program 
Protection  Plan  (PPP) ,  of  18  Jul  2011  with  Program  Protection 
Plan  Outline  includes  Annex  E  Acquisition  Information  Assurance 
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Strategy  Outline.  See  reference  (b) ,  enclosure  4,  for 
implementation  requirements  for  all  DON  ACAT  programs. 

2.8.1  Anti-Tamper  Measures 

Technology  protection  is  essential  to  maintain 
technological  superiority  over  a  system's  life.  Additionally, 

DoD  seeks  to  cooperatively  develop  systems  with  other  countries 
and  permit  Foreign  Military  Sales  (FMS)  or  Direct  Commercial 
Sales  (DCS) ,  which  promote  resource  conservation, 
standardization,  commonality,  and  interoperability.  Co¬ 
development,  sales,  transfer  loss  on  the  battlefield,  and/or 
unintended  diversion  will  expose  critical  technology  to  potential 
exploitation  or  reverse-engineering  attempts.  This  unintentional 
technology  transfer  risk  must  be  addressed  by  assessing, 
designing,  and  implementing  appropriate  AT  measures. 

DON' s  AT  Technical  Agent  (Office  of  Naval  Research  (ONR) ) 
will  support  PMs  and  DON' s  AT  Technical  Authority  (NAVAIRSYSCOM) 
on  AT  technical  matters . 

2. 8. 1.1  Program  Protection  Plan  AT  Annex 

All  ACAT  programs  are  now  required  by  PDUSD(AT&L) 
memorandum  of  18  Jul  2011  (see  the  memorandum  at  the  Web  site 
link  in  paragraph  2.8)  to  develop  a  Program  Protection  Plan  with 
an  AT  annex.  The  DON  AT  technical  agent  will  be  available  to 
assist  the  PM  in  preparing  and  staffing  the  AT  annex.  A  final 
Program  Protection  Plan  AT  annex  will  be  submitted  to  DASN (RDT&E) 
CHSENG  via  the  DON  AT  technical  agent  for  AT  annex  technical 
concurrence  at  least  60  days  prior  to  any  program  decision  point 
(i.e.,  milestone,  FMS  decision  date,  etc) .  Effective  AT  annex 
development  should  include  the  following: 

a.  Identify  critical  program  information,  technologies, 

and  cyberspace  protection  per  references  (n) ,  (o) ,  (p) ,  (q) ,  (r) , 

(s)  ,  and  the  Militarily  Critical  Technologies  List 

(http : // www .dhra.mil/perserec/csg/tlthreat/mctl. htm) . 

b.  Assess  the  vulnerabilities  and  risk  of  inadvertent 
technology  transfer  over  the  planned  service  life.  FMS  and  DCS 
should  be  assumed  for  most  programs  unless  compelling  evidence 
exists  to  the  contrary. 

c.  Identify  potential  technical  solutions,  determine 
likely  cost  and  schedule  implications,  and  select  methods  best 
suited  to  the  respective  acquisition  effort.  Early  liaison  with 
the  DON  AT  Technical  Agent  can  assist  in  effective  technical 
solution  selection.  The  cost  must  be  identified  and  resourced  by 
the  OPNAV  Sponsor  early  in  the  program's  life  cycle. 
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d.  Develop  and  resource  the  validation  &  verification  of 
the  planned  AT  implementation. 

DASN (RDT&E)  CHSENG  should  be  consulted  for  any  revised  DoD 


AT  Executive  Agent  directed  AT 
impact  an  acquisition  program. 

2 . 9  Periodic  Reporting 

2.9.1  Program  Plans 

The  below  discussion  of 
imply  that  the  plans  addressed 
planning  documents  that  are  or 
program. 


policy  and  guidelines  which  might 


specific  program  plans  does  not 
here  constitute  all  of  the 
may  be  required  of  a  specific 


If  international  access,  participation,  or  sales  is 
planned  or  anticipated,  the  Program  Protection  Plan  will  include 
as  annexes  a  Technology  Assessment  and  Control  Plan  (TA/CP) 
(approved  by  the  MDA)  and  a  delegation  of  disclosure  authority 
letter  (DDL)  (approved  by  ASN (RD&A)  or  formally  delegated 
disclosure  authority) . 


A  Systems  Engineering  Plan  (SEP)  is  a  mandatory  milestone 
document  that  is  required  at  Milestones  A,  B,  and  C  and  also 
program  initiation  for  ships.  The  SEP  is  a  stand-alone  document. 
The  SEP  should  detail  the  overall  systems  engineering  process  and 
effort  to  be  used,  how  that  process  supports  the  assessment  of 
technical  health  and  technical  baseline  management,  how  technical 
reviews  will  be  used  to  support  program  decisions,  and  how  the 
systems  engineering  effort  relates  to  other  program  activities 
and  plans.  The  SEP  Outline,  Version  1.0  is  provided  at  the 
following  Web  site:  http : / /www. acq. osd.mil/se/ do cs/PDUSD- 
Approved .SEP  Outline -04-20-2011. docx. 


A  Life-Cycle  Sustainment  Plan  (LCSP)  is  a  mandatory 
program  plan  for  all  ACAT  programs.  The  LCSP  is  initially 
developed  at  Milestone  A  concurrent  with  the  development  of  the 
initial  SEP,  updated  for  Milestones  B  and  C  and  Full-Rate 
Production  Decision  Review,  and  should  be  updated  thereafter  as 
product  support  is  revised  during  operations  and  support  and  in 
advance  of  post-IOC  Sustainment  Gate  Reviews.  The  LCSP  Outline, 
Version  1.0  is  provided  at  the  following  Web  site: 
https ://acc. dau .mil/ adl/ en-US/472772/file/60424/PDUSD- 
Approved .LCSP  Outline -08-10-2011. docx. 

Preparation  of  a  HSI  Plan  (HSIP)  to  document  the  process 
for  effective  planning  and  implementation  of  HSI  activities  is 
discretionary  and  may  be  required  by  the  MDA  or  PM.  An  HSIP 
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would  assist  in  summarizing  HSI  planning  for  the  acquisition 
strategy.  PMs  should  prepare  an  HSIP  before,  or  as  soon  as 
possible  after,  program  initiation.  An  HSIP  facilitates  the 
integration  of  the  HSI  domains  among  themselves  and  between  the 
HSI  team  and  all  stakeholders.  The  HSIP  should  include  an  HSI 
issues  audit  trail  that  identifies  and  describes  issues  or 
concerns;  plans  to  address  each  issue/concern;  actions  taken  or 
decisions  made;  tradeoff  decisions/reasons  when  costs  or  other 
constraints  prohibit  adoption  of  optimal  HSI  solutions  or  impact 
on  performance  and/or  risk  mitigation  strategies;  those 
responsible  for  action  taken  or  decisions  made;  and  the  current 
status  of  each  issue/concern.  The  HSIP  should  be  a  living 
document  that  is  updated  as  the  program  evolves. 

Preparation  of  a  System  Safety  Program  Plan  (SSPP)  is 
discretionary  and  may  be  required  by  the  MDA  or  PM.  A  SSPP 
describes  the  tasks  and  activities  required  to  implement  the 
system  safety  program  and  includes  organizational 
responsibilities,  resources,  methods  of  accomplishment, 
milestones,  depth  of  effort  and  integration  with  other  program 
engineering  and  management  activities  and  related  systems.  PMs 
who  develop  an  HSIP  are  encouraged  to  integrate  the  SSPP  and  the 
HSIP  into  a  single  document  or  a  single  addendum  to  the 
acquisition  strategy. 

2.9.2  Acquisition  Program  Baseline  (APB)  Reporting 

The  PM  reports  the  current  estimate  of  each  APB  parameter 
periodically  to  the  MDA.  The  PM  reports  the  current  APB 
estimates  for  ACAT  I  and  IA  programs  quarterly  in  the  DAES  which 
is  provided  via  Dashboard.  Program  goals  of  those  programs  that 
are  part  of  a  system  of  systems  (SoS)  or  family  of  systems  (FoS) 
will  be  established  in  the  context  of  an  individual  system 
executing  one,  or  more,  mission  capabilities  of  the  SoS  or  FoS. 

See  the  Defense  Acquisition  Guidebook  and  annex  2-A  of 
this  chapter  for  APB  implementing  guidance  for  all  DON  ACAT 
programs . 

2.9.3  Defense  Acquisition  Executive  Summary  (DAES) 

(DD-AT&L (Q) 1429) 

[ from  SNI  5000.2E,  2.9.3:  DAES  monthly  charts  and 
information  are  required  for  ACAT  I  and  IA  programs  and 
subprograms  of  ACAT  I  programs.  The  DAES  monthly  charts  shall  be 
submitted  to  ASN (RD&A)  no  later  than  the  20th  of  each  month,  and 
the  quarterly  information  shall  be  inputted  into  Dashboard  for 
ASN (RD&A)  review  no  later  than  the  20th  day  of  the  program's 
designated  quarterly  reporting  month.  Data  will  be 
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electronically  provided  from  Dashboard  to  USD (AT&L) ' s  DAMIR  and 
SOA  Systems  by  the  28th  of  each  month.] 

Reference  (b) ,  enclosure  4,  requires  ACAT  I/IA  DAES 
reporting  which  shall  be  in  the  Defense  Acquisition  Management 
Information  Retrieval  (DAMIR)  System  format  (see  the  Defense 
Acquisition  Guidebook) . 

2. 9. 3.1  DAES  Reporting 

Under  Secretary  of  Defense  (Acquisition,  Technology,  and 
Logistics)  (USD (AT&L))  assigns  DAES  reporting  responsibility. 
Selected  ACAT  I/IA  programs  are  assigned  a  designated  reporting 
month  by  USD (AT&L)  to  begin  their  quarterly  DAES  reports.  DAES 
data  will  be  electronically  provided  from  Dashboard  to 
USD (AT&L)' s  DAMIR  System  by  the  28th  of  the  program's  designated 
quarterly  reporting  month.  To  meet  this  deadline  and  to  allow 
adequate  time  for  ASN (RD&A)  and  ASN  (Financial  Management  and 
Comptroller)  (ASN (FM&C) )  review,  DAES  monthly  charts  are  to  be 
submitted  to  ASN (RD&A)  no  later  than  the  24th  of  each  month,  and 
the  quarterly  information  shall  be  inputted  into  Dashboard  for 
ASN (RD&A)  review  no  later  than  the  24th  day  of  the  program's 
designated  quarterly  reporting  month. 

2.9.4  Selected  Acquisition  Report  (SAR)  --  (DD-AT&L (Q&A) 823) * 

[from  SNI  5000.2E,  2.9.4:  The  Secretary  of  Defense  is 
required  to  submit  to  Congress  a  SAR  for  each  ACAT  I  MDAP  and 
subprograms  of  ACAT  I  MDAPs.  Waivers  may  be  granted  by  the 
USD (AT&L)  for  certain  pre-milestone  B  programs  that  do  not  have 
an  approved  APB.  The  SAR  provides  to  Congress  standard, 
comprehensive  summary  reporting  of  cost,  schedule ,  and 
performance  information  on  each  ACAT  I  program.  The  annual  SAR 
report,  covering  the  period  ending  31  December ,  shall  be 
submitted  to  ASN (RD&A)  no  later  than  the  15th  day  after  the 
President  sends  the  budget  to  Congress . 

Quarterly  SARs ,  which  are  submitted  on  an  exception  basis, 
shall  be  forwarded  no  later  than  the  15th  day  after  the  end  of 
the  reporting  quarter.  Exception  SAR  reporting  is  required  for 
programs  when:  1)  the  current  estimate  exceeds  the  current  APB 
objective  for  the  program  acquisition  unit  cost  (PAUC)  or  the 
average  procurement  unit  cost  (APUC)  by  15  percent  or  more;  2) 
the  current  estimate  exceeds  the  original  APB  objective  for  PAUC 
or  APUC  by  30  percent  or  more;  3)  the  current  estimate  includes  a 
6 -month  or  greater  delay,  for  any  APB  schedule  parameter ,  that 
has  occurred  since  the  current  estimate  reported  in  the  previous 
SAR;  or  4)  milestone  B  or  milestone  C  approval  occurs  within  the 
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reportable  quarter.  ] 

SAR  preparation  implementation  guidance  for  ACAT  I 
programs  is  provided  in  the  Defense  Acquisition  Guidebook. 

*The  SAR  is  not  applicable  to  ACAT  IA  programs. 

However,  MAIS  programs  are  responsible  for  compliance  with 
the  statutory  requirement  for  MAIS  annual  and  quarterly 
congressional  reports  when  a  significant  or  critical  cost  growth 
has  occurred  and  for  quarterly  cost,  schedule,  and  performance 
variance  reporting  following  initial  submission  of  a  MAIS  annual 
report  to  Congress  (Jeffrey  Olson  SPAWAR-042/PEO  C4I-032). 

2.9.5  Unit  Cost  Reports  (UCRs)  —  (DD-AT&L (Q&AR) 1591) * 

*UCRs  are  not  applicable  to  ACAT  IA  programs. 

2.9.6  Past  Performance  Reporting/Reports 

The  DON  automated  system  for  reporting  contractor  past 
performance  is  the  Contractor  Performance  Assessment  Reporting 
System  (CPARS)  which  is  accessible  via  the  Internet  at 
http : / /www. cpars.csd.disa.mil/.  PM' s  have  the  responsibility  for 
providing  an  annual  assessment  of  their  contractors'  performance 
via  the  CPARS. 

2.9.7  Defense  Acquisition  Management  Information  Retrieval 
(DAMIR)  System 

See  the  Defense  Acquisition  Guidebook  for  DAMIR  System 
implementation  guidance  for  SARs  for  ACAT  I  programs  and 
Acquisition  Program  Baselines  for  all  ACAT  programs. 

2.10  Program  Certification  and  Assessments 

2.10.1  Certification  Requirements  at  Milestone  A 

2.10.2  Certification  Requirements  at  Milestone  B 

2.10.3  Assessments  Required  Prior  to  Approving  the  Start  of 
Construction  on  First  Ship  of  Shipbuilding  Program 
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Annex  2 -A 

Weapon  System  and  IT  System  Programs 
Acquisition  Program  Baselines  (APBs)/ 
APB  Deviations 


1 . 1  Acquisition  Program  Baseline  (APB) 

Per  references  (a)  and  (b) ,  every  ACAT  program  shall 
establish  an  APB  that  documents  the  cost,  schedule,  and 
performance  objectives  and  thresholds  of  that  program.  The 
initial  APB  will  be  prepared  in  connection  with  the  program' s 
initiation,  and  will  be  maintained  and  updated  as  necessary  per 
below  guidance  until  the  program  is  no  longer  on  the  active  ACAT 
program  list. 

1.1.1  Objectives  and  Thresholds 

[from  SNI  5000. 2E,  1.1. 2. 3:  All  CDD  KPPs  (and  KSAs 
supporting  the  sustainment  KPP)  shall  be  inserted  verbatim  in  the 
performance  section  of  the  acquisition  program  baseline  (APB) . ] 

Per  reference  (b) ,  each  parameter  shall  include  both  an 
objective  and  threshold  value.  If  no  threshold  is  specified, 
then  the  threshold  value  will  be  considered  the  same  as  the 
objective  value.  The  APB  will  incorporate  all  of  the  parameters 
objectives  and  thresholds  specified  in  the  capabilities  document 
(e.g.,  the  Capability  Development  Document  (CDD)  or  the 
Capability  Production  Document  (CPD) ) .  PMs  for  DON  ACAT  programs 
may  propose  additional  program  parameters,  with  associated 
objectives  and  thresholds,  for  approval  by  the  milestone  decision 
authority  (MDA) .  Program  objectives  and  thresholds  must  be 
quantifiable  and  measurable. 

PMs  will  not  make  trade-offs  in  cost,  schedule,  and/or 
performance  outside  of  the  trade  space  between  objective  and 
threshold  values  without  first  obtaining  approval  from  the 
appropriate  requirements/functional  and  resource  sponsors,  and 
from  the  MDA. 

For  those  programs  that  are  part  of  a  SoS  or  FoS, 
objectives  and  thresholds  are  to  be  established  per  the  SoS  or 
FoS  Capstone  Requirements  Document  (CRD) . 

1.1.2  APB  Content 

The  APB  content  for  all  ACAT  DON  programs,  including 
those  APBs  revised  as  a  result  of  program  modifications,  will 
represent  the  program  as  it  is  expected  to  be  developed. 
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produced,  and  deployed. 

1.1. 2.1  Performance  Parameters 

The  total  number  of  performance  parameters  should  be  the 
minimum  number  needed  to  characterize  the  major  drivers  of 
operational  performance,  sustainment,  and  interoperability.  The 
minimum  number  includes  the  KPPs  identified  in  the  CDD  or  the 
CPD . 


1.1. 2. 2  Schedule  Parameters 

Schedule  parameters  should  minimally  include  dates  for 
program  initiation,  major  decision  points,  and  the  attainment 
of  initial  operating  capability  (IOC) . 

The  threshold  value  for  an  APB  schedule  parameter  should 
normally  be  the  objective  value  plus  six  months. 

1.1. 2. 3  Cost  Parameters 

The  APB  cost  section  of  all  DON  ACAT  programs  should 
reflect  the  same  parameters  as  those  used  in  the  format  of  the 
DAMIR  System  generated  APB  for  ACAT  I  programs.  All  cost 
parameter  objectives  and  thresholds  established  in  an  APB 
should  be  stated  in  constant  base  year  dollars,  with  the  base 
year  clearly  identified.  The  APB  cost  parameters  should 
include:  1)  the  total  cost  for  each  separate  cost  parameter 
(RDT&E,  procurement,  military  construction  (MILCON) , 
acquisition  operations  and  maintenance  (O&M) ,  and  operating  and 
support  (O&S) ) ;  2)  total  quantity  (including  both  fully- 
configured  development  and  production  units) ;  3)  average 
procurement  unit  cost  (defined  as  the  total  procurement  cost 
divided  by  total  procurement  quantity);  4)  program  acquisition 
unit  cost  (defined  as  the  total  of  all  acquisition  related 
appropriations  divided  by  the  total  quantity  of  fully 
configured  end  items  (including  Engineering  Development  Models 
(EDMs)));  and  5)  the  total  costs  of  any  other  cost  objective (s) 
designated  by  the  MDA.  Consistent  with  the  scope  of  costs 
presented  in  DAMIR  for  ACAT  I  programs,  the  cost  parameters 
presented  in  the  APB  cost  section  for  programs  of  all  ACATs 
should  reflect  program-funded  costs  (also  known  as  direct 
costs)  only,  so  that  breach  determinations  can  be  made  simply 
by  comparing  the  APB  values  to  the  sum  of  (a)  sunk  costs,  (b) 
the  program's  funding  through  the  FYDP  and  (c)  the  program's 
estimated  outyear  funding. 

In  addition,  APBs  should  include  a  total  ownership  cost 
(TOC)  parameter  consisting  of  direct  costs  (RDT&E,  procurement, 
MILCON,  acquisition  items  procured  with  operations  and 
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maintenance  funds,  and  operations  and  support) ,  indirect  costs 
(attributable  to  the  program's  system),  and  infrastructure 
costs  (not  attributable  to  the  program's  system)  for  the  life 
of  the  program.  TOC  and  quantity  amount  parameters  do  not 
require  a  threshold  as  they  are  not  breachable  parameters. 

Cost  figures  for  all  APBs  should  reflect  realistic 
estimates  to  achieve  performance  objectives  of  the  total 
program,  including  a  thorough  assessment  of  risk.  Baseline 
costs  should  include  the  total  program,  not  just  the  amount 
funded  in  the  budget  and  programmed  through  the  future  years 
defense  program  (FYDP)  (i.e.,  baseline  costs  should  include 
out-year  (beyond  the  FYDP)  funding  requirements  that  are  part 
of  the  approved  program) .  Budgeted  amounts  should  not  exceed 
the  total  cost  thresholds  in  the  APB. 

The  threshold  values  for  the  cost  parameters  should 
normally  be  the  objective  value  plus  10  percent. 

1.1.3  Evolutionary  Acquisition 

When  delivering  systems  under  an  evolutionary 
acquisition  strategy,  the  APB  will  include  parameters  for  the 
next  increment  and,  if  known,  for  follow-on  increments.  These 
follow-on  increments  should  be  established  as  a  separate  end 
item  within  the  APB,  where  logical  and  feasible.  Objectives 
and  thresholds  for  cost,  schedule,  and  performance  will  be 
included  within  the  APB  for  each  block/increment ,  in  the  level 
of  detail  available  at  the  time. 

When  determining  whether  an  effort  should  be  considered  an 
evolutionary  acquisition,  the  question  to  be  answered  is  whether 
the  new  effort  is  of  an  evolutionary  or  "revolutionary"  nature. 

If  the  new  effort  is  a  drastic  change  or  improvement  that  is 
"revolutionary"  (as  opposed  to  evolutionary)  to  the  performance 
of  the  older  effort,  then  the  new  effort  must  be  considered  as  a 
separate  and  distinct  new  ACAT  program  and  not  simply  a  separate 
increment/end  item  within  the  existing  ACAT  program  and  APB. 

1 . 2  Procedures 

1.2.1  Preparation  and  Approval 

All  ACAT  program  APBs  will  be  prepared  by  the  PM  and 
approved  by  the  MDA  as  part  of  the  mandatory  program  decision 
point  information  provided  at  program  decision  point  meetings. 

Once  the  revised  APB  has  been  approved  by  the  MDA,  the 
funding  associated  with  the  revised  APB  is  to  be  reflected  in  the 
next  FYDP  update  and  is  to  be  the  new  program  funding. 
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IT  program  APBs  will  be  prepared  by  the  PM  in  coordination 
with  the  user  or  user's  representative. 

1.2. 1.1  ACAT  I,  IA,  and  II  Endorsements 

All  APBs  for  ACAT  I,  IA,  and  II  programs  will  be  endorsed 
by  the  Program  Executive  Officer  (PEO) ,  Systems  Command  (SYSCOM) 
Commander,  or  Direct  Reporting  Program  Manager  (DRPM)  (as 
appropriate) . 

Once  the  APB  has  been  endorsed  by  the  PEO,  SYSCOM,  or 
DRPM,  it  will  be  forwarded  concurrently  to  the  following 
organizations  for  endorsement: 

a.  CNO  (Information  Dominance  (N2/N6) ,  or  Fleet  Readiness 
and  Logistics  (N4),  (as  appropriate)),  and 

b.  CNO  (Integration  of  Capabilities  and  Resources  (N8)) 
or  CMC  (Deputy  Commandants,  Programs  and  Resources  (DC,  P&R)  and 
Combat  Development  and  Integration  (DC,  CD&I) ) . 

From  the  date  the  ACAT  I,  IA,  and  II  APBs  are  forwarded  to 
CNO/CMC  organizations,  there  is  a  30-calendar  day  time  limit  to 
complete  the  concurrence/endorsement  process.  Concurrence  will 
be  assumed  after  30  days  unless  a  specific  non-concurrence  has 
been  forwarded.  For  the  ACAT  I  and  II  program  APBs,  DASN (M&B) 
will  coordinate  the  signatures  and  responses  to  ensure  that  the 
appropriate  concurrences  have  been  received. 

IT  program  APBs  will  be  endorsed  by  the  IT  functional  area 
point  of  contact/manager . 

1.2. 1.2  ACAT  III  and  IV  Endorsements 

ACAT  III  and  IV  program  APBs  will  be  prepared  by  the  PM, 
endorsed  by  the  program/resource  sponsor  and  IT  functional  area 
point  of  contact/manager  and  CMC  (DC,  CD&I)  for  Marine  Corps 
programs,  and  approved  by  the  MDA. 

1.2. 1.3  Approval 

For  ACAT  I  weapons  systems  programs,  the  APB  will  not  be 
approved  without  the  coordination  of  the  Under  Secretary  of 
Defense  (Comptroller)  (10  U.S.C.  Section  2220(a)(2))  and  the 
Joint  Requirements  Oversight  Council. 

APBs  will  be  prepared  by  PMs  and  approved  at  program 
initiation  by  MDAs;  revised  and/or  updated  at  each  subsequent 
program  decision  point;  and  revised  following  an  MDA-approved 
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program  restructure  or  an  unrecoverable  program  deviation  from 
the  current  APB.  Any  required  changes  to  the  APB  resulting  from 
one  of  these  conditions  will  be  processed  and  approved  in  the 
form  of  a  revised  APB.  APBs  are  not  to  be  updated  for  the  sake 
of  providing  current  information  that  is  within  the  trade  space 
between  the  established  objective  and  threshold  values. 

The  APBs  for  ACAT  I  and  IA  programs  will  be  provided  to 
DASN  (RD&A)  (Management  and  Budget  (M&B) )  in  the  DAMIR  System 
format . 

1.2.2  OPNAV  Processing  Procedures 

1.2. 2.1  APB  and  CDD/CPD  Coordination 

For  weapon  and  IT  system  programs,  the  PM  will  provide  a 
copy  of  the  draft  APB  to  the  RO/program  sponsor  for  review  and 
validation  that  the  performance  parameters  are  consistent  with 
the  approved  CDD  or  CPD. 

1.2. 2. 2  OPNAV  Endorsement  Procedures 

The  focal  point  for  OPNAV  review  of  APBs  is  the  resource 
sponsor' s  requirements  officer  (RO) ,  with  whom  the  PM  will 
coordinate  during  APB  preparation.  To  facilitate  the  OPNAV 
review,  the  PM  will  supply  copies  of  the  APB  to  the  RO  for  the 
review  coordination.  Close  coordination  between  the  RO  and  the 
CNO  (N8)  action  officer  is  required  for  an  expeditious  OPNAV 
review.  The  RO  will  provide  OPNAV  comments  to  the  PM  and  will 
attempt  to  resolve  all  OPNAV  issues  with  the  PM. 

When  staffing  APBs  for  CNO  (N8)  endorsement,  the  resource 
sponsor  should  provide  the  additional  following  information  to 
the  CNO  (N8)  staff: 

a.  The  reason  for  changing/updating  the  APB  (i.e.,  to 
support  a  program/milestone  decision  point  (providing  the 
relationship  of  the  decision  to  the  overall  progress  of  the 
program)  or  to  document  changes  to  program  cost,  schedule,  and/or 
performance  parameters  that  are  outside  the  approved  objective- 
threshold  ranges) ; 

b.  The  FYDP  Budget  display  for  the  program  with  an 
indication  regarding  whether  or  not  the  program  is  fully  funded 
across  the  FYDP  in  all  appropriations  (i.e.,  RDT&E,  SCN,  APN, 
etc.) .  Include  a  comparison  of  the  program  budget  requirements 
versus  budget  authorized; 

c.  The  last  approved  schedule  of  record  for  the  program; 
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d.  Any  Congressional  language  or  interest  in  the  program 
or  effort;  and 

e.  Any  technical,  testing,  or  programmatic  concerns  that 
might  impact  the  decision  at  hand. 

1 . 3  APB/Program  Deviations  Procedures 

1.3.1  APB/Program  Deviations 

A  program  deviation  occurs  when  the  PM  has  reason  to 
believe  that  the  current  estimate  of  an  APB  cost,  performance,  or 
schedule  parameter  will  breach  the  threshold  value  for  that 
parameter.  When  a  program  deviation  occurs,  the  PM  should 
immediately  notify:  the  MDA,  via  ASN (RD&A)  and  the  PEO/SYSCOM 
Commander,  for  ACAT  ID  and  IAM  programs;  the  MDA,  via  the 
PEO/SYSCOM  Commander,  for  ACAT  IC,  IAC,  and  II  programs;  or  the 
MDA  for  ACAT  III  and  IV  programs. 

If  ASN (RD&A)  determines  there  is  a  significant  or  critical 
unit  cost  breach  of  an  ACAT  I  program  or  subprogram,  ASN (RD&A) 
will  notify  USD(AT&L)  and  SECNAV.  The  senior  official  for 
Program  Assessment  and  Root  Cause  Analysis  (PARCA)  will  conduct  a 
root  cause  analysis  of  a  critical  unit  cost  breach  of  an  ACAT  I 
program  or  subprogram  and  provide  the  root  cause  analysis  to  the 
OSD  Director  of  Cost  Assessment  and  Program  Evaluation  who  will 
provide  USD(AT&L)  via  ASN (RD&A)  a  program  assessment  required  by 
Public  Law  111-23  of  22  May  2009,  section  206. 

Within  30  days  of  a  program  deviation,  the  PM  should 
notify  the  MDA  of  the  reason  for  the  deviation  and  the  action  (s) 
being  taken  to  bring  the  program  back  within  the  approved 
baseline  thresholds.  Within  90  days  of  the  program  deviation, 
the  PM  should: 

a.  Ensure  the  program  is  back  within  APB  thresholds,  or 

b.  Submit  a  new  APB,  changing  only  the  breached  parameter 
and  those  parameters  directly  affected  by  the  breached  parameter, 
or 


c.  Provide  a  date  by  which  the  new  APB  will  be  submitted 
or  by  which  the  program  will  be  back  within  original  APB 
thresholds . 

d.  Keep  the  CNO/CMC  (DC,  P&R  and  DC,  CD&I)  informed 
with  regard  to  program  deviations  and  baseline  recovery 
actions . 


1.3. 1.1  APB/Program  Deviation  Report/Notification 
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An  APB/Program  Deviation  Report/Notification  should 
contain  the  following  minimum  information  for  the  breached  APB 
parameter (s)  and  corrective  actions: 

a.  Breached  APB  parameter  threshold  and  objective  values. 

b.  Current  estimate  of  the  breached  APB  parameter. 

c.  PM' s  corrective  actions  initiated  to  arrest/mitigate 
the  breach. 

d.  Industry  actions  to  arrest/mitigate  the  breach. 

e.  New/additional  corrective  actions  to  minimize  the 
extent  of  the  breach  and  reduce  risk  of  further  breach. 

f.  Explicit  statement  of  Nunn-McCurdy  impacts;  i.e., 
PAUC/APUC  percent  cost  growth  to  current  and  original  baselines. 

g.  Management  actions  instituted  to  raise  the  visibility 
of  the  breach,  including  award  fee/CPARS  implications  and  regular 
progress  reports  on  the  efficacy  of  corrective  actions. 

h.  A  plan  of  action  for  preparing  and  routing  the  new  APB 
per  paragraph  1.3.3. 

i.  For  quantity  related  breaches  (including  "good" 
breaches) ,  provide  the  rationale  for  the  change  in  quantity. 

j .  Fact-finding  to  address  the  above  items  should  not 
slow  down  the  timely  notification  of  breaches. 


1.3.2  Program  Deviation  Criteria 


Unless  otherwise  specified,  the  value  of  a  performance 
objective  or  threshold  in  the  APB  should  not  differ  from  the 
value  for  a  like  objective  or  threshold  value  in  the  CDD/CPD,  and 
their  definition  should  be  consistent. 


For  weapon  and  IT  system  programs  the  threshold  value  for 
schedule  should  normally  be  the  objective  value  plus  6  months; 
and  the  threshold  value  for  cost  should  normally  be  the  objective 
value  plus  10  percent. 


1.3.3  Revised  Baseline  Approval 


If  a  program  cannot  be  brought  back  within  the  current 
APB,  the  PM  prepares  a  revised  APB,  and  obtains  the  same 
endorsements  and  approvals  using  the  same  paragraph  1.2 
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procedures  as  required  for  the  initial  APB.  For  all  ACAT 
programs,  resource  sponsors  will  review  the  APB/program  deviation 
report/notification  and  commit  to  continued  funding,  if 
appropriate,  by  signing  an  OPNAV  coordination  sheet  for  the 
APB/program  deviation  report/notif ication . 

1 . 4  Responsibilities 

1.4.1  PM 

The  PM  will  maintain  the  currency  and  adequacy  of  the  APB 
from  program  initiation  until  the  program  is  no  longer  on  the 
active  ACAT  program  list.  See  SECNAVINST  5000. 2E,  paragraph  2.4 
for  discussion  of  active  ACAT  program  list. 

1.4.2  IT  Functional  Area  POC/Manager 

The  IT  functional  area  POC/manager/user' s  representative 

will : 


a.  Ensure  KPPs  from  the  CDD  or  CPD  are  extracted  and 
included  in  the  APB. 

b.  Ensure  consistency  with  principal  staff  assistant's 
functional  planning  and  target  architecture. 

c.  Review  and  endorse  the  APB. 

1.4.3  Program/Resource  Sponsors 

1.4. 3.1  ACAT  I,  IA,  and  II  Programs 

The  program/resource  sponsors  and  CNO  (N2/N6  or  N4  or  N9 
and  N8)  or  CMC  (DC,  P&R  and  DC,  CD&I)  will  endorse  APBs  and  APB 
revisions . 

1.4. 3. 2  ACAT  III  and  IV  programs 

The  program/resource  sponsors  and  CMC  (DC,  CD&I)  will: 

a.  Endorse  the  APB. 

b.  Review  and  endorse  all  APB  revisions. 

1.4.4  MPA 

The  MDA  will  approve  the  initial  APB  and  all  APB 
revisions . 
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1.4.5  Product  DASNs  and  DASN (M&B) 

Product  DASNs  and  DASN (M&B)  will  track  ACAT  I  and  IA 
programs  using  DASHBOARD  and  advise  ASN (RD&A)  when  program 
execution  is  at  risk  of  breaching  APB  thresholds. 


2-32 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


Acquisition  Program  Baseline  Signature  Page  (Weapon  System) 

CLASSIFICATION 

Acquisition  Program  Baseline 
Program  XXX 

With  the  objective  of  enhancing  program  stability  and  controlling  cost 
growth,  we,  the  undersigned,  concur  with,  and  the  MDA  approves,  this  baseline 
document.  Our  intent  is  that  the  program  be  managed  within  the  programmatic, 
schedule,  and  financial  constraints  identified.  We  agree  to  support,  within 
the  charter  and  authority  of  our  respective  official  positions,  the  required 
funding  in  the  Planning,  Programming,  Budgeting,  and  Execution  System  (PPBES) . 

This  baseline  document  is  a  summary  and  does  not  provide  detailed  program 
requirements  or  content.  It  does,  however,  contain  key  performance,  schedule, 
and  cost  parameters  that  are  the  basis  for  satisfying  an  identified  capability 
need.  As  long  as  the  program  is  being  managed  within  the  framework 
established  by  this  baseline,  in-phase  reviews  will  not  be  held  unless 
directed  by  the  MDA. 


Program  Manager  (All  ACAT  programs) 

Date 

Program  Executive  Of f icer/SYSCOM/DRPM  (All  ACAT  programs) 

[If  the  MDA,  signature  should  be  after  CNO/CMC] 

Date 

CNO  (Program/Resource  Sponsors)  (All  ACAT  programs) 

or  CMC  (Deputy  Commandant,  Combat  Development  and  Integration) 

programs ) 

(All 

Date 

USMC  ACAT 

CNO  (Information  Dominance  (N2/N6) )  (ACAT  I/II  programs) 
or  CNO  (Fleet  Readiness  and  Logistics  (N4 ) )  (ACAT  I/II  programs 
or  CNO  (Warfare  Systems  (N9))  (ACAT  I/II  programs) 

) 

Date 

CNO  (Integration  of  Capabilities  and  Resources  (N8))  (ACAT  I/II  programs)  Date 
or  CMC  (Deputy  Commandant,  Programs  and  Resources)  (USMC  ACAT  I/II  programs) 

ASN (RD&A) ,  or  designee  (ACAT  I/II  programs) 

Date 

Under  Secretary  of  Defense  (Acquisition,  Technology 

Date 

and  Logistics)  (ACAT  ID  programs) 

Derived  from: 

Declassify  on: 

CLASSIFICATION 
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Acquisition  Program  Baseline  Signature  Page  (IT  System) 

CLASSIFICATION 

Acquisition  Program  Baseline 
Program  XXX 

With  the  objective  of  enhancing  program  stability  and  controlling  cost 
growth,  we,  the  undersigned,  concur  with,  and  the  MDA  approves,  this  baseline 
document.  Our  intent  is  that  the  program  be  managed  within  the  programmatic, 
schedule,  and  financial  constraints  identified.  We  agree  to  support,  within 
the  charter  and  authority  of  our  respective  official  positions,  the  required 
funding  in  the  Planning,  Programming,  Budgeting,  and  Execution  System  (PPBES) . 

This  baseline  document  is  a  summary  and  does  not  provide  detailed  program 
requirements  or  content.  It  does,  however,  contain  key  performance,  schedule, 
and  cost  parameters  that  are  the  basis  for  satisfying  an  identified  capability 
need.  As  long  as  the  program  is  being  managed  within  the  framework 
established  by  this  baseline,  in-phase  reviews  will  not  be  held  unless 
directed  by  the  MDA. 


Program  Manager  Date  IT  Functional  Area  POC/Manager  Date 

(All  ACAT  IT  programs)  (All  ACAT  IT  programs) 


Program  Executive  Of f icer/SYSCOM/DRPM  (All  ACAT  IT  programs)  Date 

[If  the  MDA,  signature  should  be  after  CNO/CMC] 


Program/Resource  Sponsors  (All  ACAT  IT  programs) 


Date 


CMC  (Deputy  Commandant,  Combat  Development  and  Integration)  Date 

(All  USMC  ACAT  IT  programs) 


CNO  (Integration  of  Capabilities  and  Resources  (N8))  (ACAT  IA  programs)  Date 
or  CMC  (Deputy  Commandant,  Programs  and  Resources)  (USMC  ACAT  IA  programs) 


Milestone  Decision  Authority  Date 

(ACAT  I AC  and  ACAT  III  and  IVT  IT  programs) 


ASN (RD&A) ,  or  designee  Date 

(ACAT  IAM  programs) 


Under  Secretary  of  Defense  (Acquisition,  Technology  and  Logistics)  Date 

or 

DoD  CIO  (ACAT  IAM  programs) 

Derived  from: 

Declassify  on: 

CLASSIFICATION 
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Chapter  3 

Information  Technology  (IT)  Considerations 


References : 


(a)  SECNAVINST  5000. 2E 

(b)  POD  Instruction  5000.02  of  8  Dec  2008 

(c)  DON  CIO  Memorandum,  Assessment  of  Compliance 
with  DON  Enterprise  Architecture  as  Part  of 
Title  40/Clinger-Cohen  Act  (Title  40/CCA) 
Compliance  Confirmation  Process,  of  21  Sep  2009 

(d)  CJCSI  6212. 01E  of  15  Dec  2008 

(e)  Department  of  Defense  Architecture  Framework 
(DoDAF)  Ver  2.0  documents,  of  28  May  2009 

( f )  POD  Directive  4630.05  of  5  May  2004 


(g) 

DOD  Instruction  4630.8  of  30  Jun  2004 

(h) 

DON  Architecture  Development  Guide  (ADG) 

Version 

2.0,  of  29  Jul  2011 

(i) 

Manual  for  the  Operation  of  the  Joint 

Capabilities  Integration  and  Development 

System, 

of  19  Jan  2012 

(j) 

DOD  Directive  8500. 01E  of  24  Oct  2002 

(k) 

DOD  Instruction  8500.2  of  6  Feb  2003 

(1) 

DOD  Instruction  8510.01  of  28  Nov  2007 

(m) 

SECNAVINST  5239. 3B 

(n) 

DOD  Directive  8570.01  of  15  Aug  2004 

(o) 

DOD  Manual  8570. 01-M,  Information  Assurance 

Workforce  Management  Program,  of  19  Dec 

2005 

(p) 

SECNAVINST  3052.2 

(q) 

OPNAVINST  5100. 23G 

3.1  Clinger-Cohen  Act  (CCA)  (Title  40  U.S.C.,  Subtitle  III) 
Compliance 

3.1.1  CCA  Compliance  Package  Development  and  Processing  for 
ACAT  I AM,  IAC,  ID,  IC,  and  II  Programs  containing  IT  Systems 
including  National  Security  Systems  (NSS) 

CCA  compliance  confirmation  shall  be  obtained  through  the 
process  described  in  reference  (a),  chapter  3,  paragraphs  3.1  and 

3.1.1. 


Title  40/CCA  confirmation  requirements  are  provided  in 
reference  (b) ,  Enclosure  5,  Table  8.  Included  is  the  requirement 
that  acquisition  programs  must  be  "consistent  with  the  GIG 
policies  and  architecture,  to  include  relevant  standards." 

Program  Managers  are  expected  to  complete  the  following  steps  in 
order  to  assert  that  their  program  is  consistent  with  GIG 
policies  and  architecture  during  the  Title  40/CCA  confirmation 
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process : 


a.  Complete  the  DON  Enterprise  Architecture  (DON  EA) 
compliance  process  in  the  DON  variant  of  the  Department  of 
Defense  Information  Technology  Portfolio  Repository  (DITPR-DON) 
pursuant  to  references  (a)  and  (c) ,  to  include  the  final 
adjudication  of  all  waiver  requests.  For  those  systems  that  have 
completed  the  DON  EA  compliance  process  as  part  of  an  Information 
Management  ( IM) / Inf ormation  Technology  (IT)  Investment/Annual 
Review  in  the  same  Fiscal  Year  as  the  CCA  confirmation  is 
required,  the  Program  Manager  is  not  required  to  reassert 
compliance  if  there  have  not  been  any  changes  to  the  program 
after  it  completed  that  DON  EA  compliance  process. 

b.  Ensure  consistency  with  all  promulgated  GIG  policies 
and  architecture  documents,  to  include  those  posted  at 
https://www.intelink.gov/wiki/Global  Information  Grid  2.0. 


c.  For  those  systems  with  a  Net-Ready  Key  Performance 
Parameter  (NR-KPP)  requirement,  provide  the  five  NR-KPP  elements 
as  specified  in  reference  (d) .  They  are: 

(1)  a  DoD  Architecture  Framework  (DoDAF)  compliant 
solution  architecture  developed  in  accordance  with  the  current 
version  of  reference  (e) ; 


(2)  compliance  with  net-centric  data  and  services 

strategies ; 

(3)  compliance  with  applicable  GIG  Technical  Guidance 

(GTG) ; 


(4)  compliance  with  DoD  Information  Assurance  (IA) 
requirements;  and, 

(5)  compliance  with  supportability  requirements  to 
include  spectrum  utilization  and  information  bandwidth 
requirements.  Selective  Availability  Anti-Spoofing  Module  (SAASM) 
and  the  Joint  Tactical  Radio  System  ( JTRS)  ,  as  applicable.  In 
situations  where  the  Information  Support  Plan  (ISP)  has  not  as 
yet  been  developed,  provide  the  NR-KPP  from  the  Capability 
Development  Document  (CDD)  or  Capability  Production  Document 
(CPD)  ,  pursuant  to  references  (f)  and  (g)  . 


d.  Develop  Solution  Architectures  based  on  guidance 
provided  in  reference  (h) . 

Pursuant  to  reference  (a) ,  confirmation  of  compliance  with 
Title  40/CCA  for  ACAT  III  and  below  IT/NSS  has  been  delegated  to 
echelon  2  command  information  officers  for  Navy  programs  and  to 


3-2 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


the  Department  of  the  Navy  Deputy  Chief  Information  Officer 
(Marine  Corps)  (DON  Deputy  CIO  (Marine  Corps) )  for  Marine  Corps 
programs.  These  same  four  steps  should  be  followed  for  CCA 
confirmation  of  these  programs,  when  asserting  consistency  with 
the  GIG  policies  and  architecture,  to  include  relevant  standards. 

3.1.2  CCA  Compliance  Package  Development  and  Processing  for 
ACAT  III,  IV,  and  Abbreviated  Acquisition  Program  (AAP)  Programs 
containing  IT  Systems  including  NSS 

CCA  compliance  confirmation  shall  be  obtained  through  the 
process  described  in  reference  (a),  chapter  3,  paragraphs  3.1  and 

3.1.2. 

3 . 2  Contracts  for  Acquisition  of  IT  Systems  including  NSS 

[ from  SNI  5000. 2E,  3.2:  No  request  for  proposal  (RFP) 
shall  be  issued ,  leading  to  a  contract  that  acquires  an  IT 
system,  including  an  NSS,  until: 

a.  The  IT  system  is  registered  in  the  DoD  IT  Portfolio 
Repository-DON  (DITPR-DON)  (contact  your  command  10  for 
assistance  with  IT  Registration) ; 

b.  The  acquisition  information  assurance  strategy  for  the 
IT  system  is  coordinated  with  the  DoD  CIO  for  ACAT  ID,  {deleted 
"IC"  in  Guidebook  pursuant  to  SECNAVINST  5000. 2E,  table  E2T1}, 
IAM,  and  IAC  programs ,  and  approved  by  the  DON  CIO  for  ACAT  ID, 
IC,  IAM,  IAC,  and  II  programs ,  or  approved  by  the  respective 
command  10  for  ACAT  III,  IV,  and  AAPs,  (a  PEO  PM  or  a  DRPM  may 
have  their  ACAT  III,  IV,  and  AAP  Acquisition  Information 
Assurance  Strategy  approved  by  the  DON  CIO.); 

c.  Compliance  with  the  CCA  (including  compliance  with 
the  DON  EA)  is  confirmed  for  ACAT  ID,  IC,  IAM,  IAC,  II,  III, 

IV,  and  AAP  program;  and 

d.  DASN (C4I  and  Space)  insight  review,  detailed  in 
paragraph  3.6  below,  has  been  completed  if  required  per  paragraph 
3.  6. 


Each  echelon  2  command  10  and  the  DON  Deputy  CIO  (Marine 
Corps)  (for  Marine  Corps  IT  system  contracts)  shall  submit  a 
report  to  DON  CIO  by  the  30th  day  after  the  end  of  each  calendar 
quarter,  identifying  ACAT  III,  IV  and  AAP  acquisition  information 
assurance  strategies  approved  or  rejected  during  the  review 
required  by  subparagraph  3.2.b.  above  (clarified  in  guidebook} . 
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When  the  use  of  commercial  IT  is  considered  viable , 
maximum  leverage  of  and  coordination  with  the  DoD  Enterprise 
Software  Initiative  (DoD  ESI)  and  the  Federal  SmartBUY  shall  be 
made.  The  DoD  ESI  is  an  initiative  led  by  the  DoD  CIO  to 
develop  processes  for  DoD-wide  software  asset  management.  The 
DoD  implements  SmartBUY  through  the  DoD  ESI  Team ,  which 
provides  DoD  commercial  software  requirements  to  SmartBUY  and 
manages  selected  SmartBUY  agreements .  DoD  ESI  and  SmartBUY 
have  jointly  established  software  agreements  for  commercial 
software  and  software  maintenance  {and  related  services  (added 
in  guidebook  for  clarification) }  that  coordinate  multiple  IT 
investments  to  leverage  the  Federal  Government's  purchasing 
power  for  best-priced ,  standards -compliant  products .  DON 
activities  purchasing  software  {and  related  services  (added  in 
guidebook  for  clarification) }  for  which  agreements  have  been 
awarded  must  follow  DFARS  208.  74  and  consider  use  of  DoD  ESI 
agreements  before  buying  elsewhere ,  and  if  there  are  existing 
SmartBUY  agreements,  they  must  use  the  SmartBUY  agreements . 

The  Web  site  http : //www. esi .mil/  provides  additional  guidance.] 

ESI  also  offers  links  for  hardware  through  the  Army's 
Consolidated  Buy  (CB)  and  the  Air  Force's  Quantum  Enterprise  Buy 
(QEB)  programs.  CB  and  QEB  provide  the  DoD  hardware  buyer  and 
enterprise-like  source  for  desktop  where  savings  are  realized 
through  consolidated  buying. 

Each  echelon  2  command  10  and  the  DON  Deputy  CIO  (Marine 
Corps)  (for  Marine  Corps  IT  system  contracts)  should  submit  a 
quarterly  report  to  DON  CIO  by  the  30th  day  after  the  end  of  each 
calendar  quarter,  identifying  ACAT  III,  IV  and  AAP  CCA 
confirmations  that  were  issued  or  rejected  during  the  review 
required  by  subparagraph  3.2.c.  above. 

See  reference  (b) ,  enclosure  5,  for  implementation 
requirements  for  all  Department  of  the  Navy  (DON)  acquisition 
category  (ACAT)  programs. 

3 . 3  Information  Integration  and  Interoperability 

Consideration  shall  be  given  to  information 
interoperability  products  described  in  reference  (e) ,  the 
Department  of  Defense  Architecture  Framework  Document,  in  the 
creation  of  capability  development/production  documents 
(CDD/CPDs) .  Interoperability  at  the  data  level  is  essential  for 
information  superiority;  the  DON  data  management  and 
interoperability  (DMI)  engineering  and  management  processes  are 
essential  in  improving  interoperability  at  this  level. 
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Within  an  information  technology  (IT),  including  NSS, 
program,  program  managers  (PMs)  should  characterize  information 
interoperability  by  extracting  the  information  exchange 
requirements  from  the  CDD/CPD  along  with  the  associated 
interoperability/Net-Ready  Key  Performance  Parameters  (KPPs) . 

This  characterization,  using  mission-area  integrated 
architectures  as  described  in  references  (f) ,  (g) ,  and  (i) ,  will 

also  be  in  the  context  of  either  a  family  of  systems  (FoS)  or  a 
system  of  systems  (SoS) ,  and  a  mission  area,  and  shall  apply  to 
all  IT  systems,  including  NSS. 

3 . 4  Information  Assurance  (IA)  Program  Manager  (PM) 
Responsibilities 

Information  Assurance  (IA)  is  the  cornerstone  to  the  DON 
transformation  to  a  secure  interoperable,  net-centric  Naval 
Information  Management  (IM)/IT  Enterprise.  The  security  and 
superiority  of  DON  information,  systems,  and  personnel  are  key  to 
maritime  dominance  and  national  security.  The  DON  takes  a 
Defense  in  Depth  (DID)  approach  to  IA,  layering  IA  principles  and 
controls  that  apply  to  people,  processes,  and  technology. 

IA  is  the  defensive  component  of  information  operations 
(10) .  IA  protects  and  defends  information  and  information 
systems  (IS)  by  ensuring  their  availability,  integrity, 
confidentiality,  authentication  and  non-repudiation.  IA  includes 
providing  for  the  restoration  of  IS  by  incorporating  protection, 
detection  and  reaction  capabilities.  The  more  interoperable  and 
information  dependent  DON  Operations  become,  the  more  important 
IA  becomes.  Without  effective  IA,  "full  spectrum  dominance"  in 
the  information  domain  is  not  achievable.  Simply  disrupting  the 
network  isolates  sensors  from  weapon  systems  and  impairs  naval 
warfighting  ability.  Infiltrating  the  network  allows  the  enemy 
to  exploit  sensors  and  understand  force  disposition. 

PMs  should  manage  and  engineer  information  systems  using 
the  best  processes  and  practices  known  to  reduce  security  risks, 
including  the  risks  to  timely  accreditation.  Per  references  (j), 
(k) ,  (1) ,  and  (m) ,  PMs  shall  address  IA  requirements  throughout 

the  life-cycle  of  all  DoD  IT  systems,  including  NSS.  The  PM 
shall  incorporate  IA  control  measures  (safeguards)  into  IT 
systems,  including  NSS,  based  upon  approved  CDD/CPD-derived 
mission  assurance  category  (MAC)  and  confidentiality  level  (CL) . 
Minimum  control  measures  described  in  reference  (k)  ensure  that 
appropriate  levels  of  availability,  integrity,  authentication, 
confidentiality,  and  non-repudiation  are  sustained.  These 
controls  will  also  allow  the  system  protection  against 
information  attack,  and  when  it  occurs,  detect,  respond,  and 
restore  the  system  to  full  functionality.  The  security 
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certification  and  accreditation  (C&A)  process  of  reference  (1) 
will  ensure  that,  based  upon  MAC  and  CL,  the  appropriate  security 
safeguards  are  properly  implemented.  References  (j)  and  (k) 
establish  the  minimum  IA  capabilities  that  are  to  be  incorporated 
in  DoD  information  systems  and  connected  IT  systems,  including 
NSS.  PMs  should  ensure  that  the  MAC  and  CL  are  identified  in  the 
acquisition  strategy. 

3.4.1  Information  Assurance  and  Integrated  Architectures 

Systems  must  exchange  information  within  the  confines  of 
the  integrated  Navy  architectures  and  the  global  information  grid 
(GIG).  Program  managers  should  use  ASD(NII)  Net-Centric 
Checklist  version  2.1.3.  of  12  May  2004  and  2.1.4  of  30  Jul  2004 
to  understand  the  net-centric  attributes  that  their  IT,  including 
NSS,  programs  need  to  implement  to  move  into  the  net-centric 
environment  as  part  of  integrated  Navy  architecture  in  the  GIG. 

A  service-oriented,  integrated  Navy  architecture  is  a  design 
style  for  building  flexible,  adaptable  distributed-computing 
environments  for  the  Department  of  Defense  (DoD) .  Service- 
oriented,  integrated  Navy  architecture  design  is  fundamentally 
about  sharing  and  reuse  of  functionality  across  diverse 
applications.  IT  systems,  including  NSS,  must  be  procured  with 
appropriate  IA  controls  so  that  they  are  "Net-Ready"  to  be 
inserted  into  integrated  Navy  architectures.  IA  control  measures 
must  be  designed  into  systems  with  careful  consideration  of  the 
context  in  which  the  integrated  architectures  will  function. 
Information  assurance  hardware  and  software  capabilities  (tools) 
must  be  assessed  for  and  meet  interoperability  requirements  as 
established  by  the  Information  Assurance  Panel  as  stated  in 
reference  (d) .  Service  and  joint  interoperability  requirements 
establish  the  context  within  which  information  is  exchanged  and 
impact  IA  controls.  Electromagnetic  environmental  effects  (E3) 
impact  information  availability  and  integrity.  Radio  frequency 
(RF)  spectrum  must  be  reserved,  available,  and  managed.  The 
system  security  certification  and  accreditation  (C&A)  process 
must  verify  and  validate  IA  controls  in  the  context  of 
architecture  within  which  it  will  function.  Net-readiness,  E3, 
spectrum  management,  system  security  C&A  and  IA  are 
interdependent  and  must  be  incorporated  into  IT  systems, 
including  NSS,  from  an  integrated  architectural  perspective. 

3.4.2  IA  Strategy  Content 

3. 4. 2.1  Policies ,  Standards ,  and  Architectures 

Describe  how  IT,  including  NSS,  program  information 
assurance  features  are  consistent  with  DoD  policies,  standards, 
and  architectures. 
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3. 4. 2. 1.1  Benchmark 

a.  Minimum  DoD  IA  requirements  are  defined  in  references 
( j )  and  (k) . 

b.  MAC  and  CL  specify  the  confidentiality,  availability, 
and  integrity  minimum  requirements  for  a  DoD  information  system 
and  a  connected  IT  system,  including  NSS. 

c.  IA  capabilities  requirements  should  be  specified  in 
the  capability  development/production  document  (CDD/CPD)  as  MAC 
and  CL  and  incorporated  into  IT,  including  NSS,  program  design 
activities . 

d.  Interoperability  requirements  affected  by  the  IA 
design  approach  are  specified  (see  reference  (k) ) . 

e.  Program  requirements  for  support  from  the  DoD  IA 
infrastructure  (e.g.,  public  key  infrastructure)  are  specified. 

f.  The  impact  of  DoD  Cryptographic  Modernization  Program 
upon  cryptographic  functions  is  addressed. 

g.  System  certification  testing  is  conducted  to  ensure 
that  CDD/CPD  stated  MAC  and  CL  security  requirements  are  met. 

h.  Information  system  survivability  is  addressed  by 
incorporating  protection,  detection,  reaction,  and  reconstitution 
capabilities  into  the  system  design. 

i.  Relevant  DON/DoD  policies  concerning  the  use  of 
evaluated  Commercial-Of f-The-Shelf  (COTS) /government-off-the- 
shelf  (GOTS)  IA  products  per  reference  (k)  are  identified. 

j  .  Information  assurance  requirements  are  addressed 
throughout  an  IT,  including  NSS,  program's  life-cycle. 

k.  To  the  extent  possible,  the  requirements  of  the 
Navy/Marine  Corps  Unclassified  Trusted  Network  Protection  Policy 
(UTNProtect  Policy)  need  to  be  supported.  Specifically,  the 
ports,  protocols,  services,  and  conditions  for  use  referenced  in 
the  Navy/Marine  Corps  UTNProtect  Policy 

(https ://infosec. navy . mil )  need  to  be  considered.  Recommended 
COTS  product  evaluations  that  could  support  the  Navy/Marine  Corps 
UTNProtect  Policy  can  also  be  found  at  https://infosec. navy.mil/ . 

3. 4. 2. 1.2  Potential  Sources 

IT,  including  NSS,  information  support  plan  (ISP),  Net- 
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Ready  Key  Performance  Parameter  (NR-KPP)  per  references  (f)  and 
(g) ,  system  security  authorization  agreement  (SSAA) ,  and  CDD/CPD 
are  potential  sources. 

3. 4. 2. 2  Certification  and  Accreditation 

Describe  the  overall  certification  and  accreditation 
approach . 


3. 4. 2. 2.1  Benchmark 

a.  All  security  requirements  are  included  in  the  testing 
strategy  for  developmental  test  and  evaluation  (DT&E)  and 
operational  test  and  evaluation  (OT&E)  , 

b.  Successful  certification  and  accreditation  of  the 
information  system  per  the  DIACAP  as  defined  in  reference  (1) . 

c.  The  responsible  Designated  Approving  Authorities 
(DAAs)  are  identified, 

d.  There  is  agreement  with  the  DAA(s)  on  the 
certification  and  accreditation  approach  (e.g.,  a  system,  type, 
or  site  certification  process  to  be  used) ,  and 

e.  The  status  of  the  program's  DIACAP  executive  package 
is  identified. 

3. 4. 2. 2. 2  Potential  Sources 

IT,  including  NSS,  ISP,  DIACAP  executive  package,  and  test 
and  evaluation  master  plan  (TEMP) . 

3.4.3  IA  Workforce 

Identifying  and  categorizing  positions  conducting  IA 
activities  in  support  of  the  GIG,  in  support  of  cyberspace 
protection,  and  certifications  required  of  those  positions,  is 
governed  by  references  (n) ,  (o) ,  and  (p) .  Program  Managers 

should  review  these  issuances  to  ensure  their  program  adheres  to 
all  procedures  and  requirements  applicable  to  the  IA  workforce, 
including  contracted  support.  The  PM  should  be  aware  that  since 
references  (n) ,  (o) ,  and  (p)  impact  contracted  support, 

SECNAVINST  5000. 2E,  chapter  7,  should  also  be  consulted. 
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3 . 5  Records  Management 

3 . 6  IT  Contract/Procurement  Management  Approval  ("Insight") 

Figure  3-1 

Information  Technology  (IT)  Acquisition  Contract/Procurement 
Substantive  Actions/Issues  Report 

REPORT  DATE: 


1.  Title :  (enter  title  of  IT  acquisition  contract/procurement) 

2.  Substantive  Actions/Issues:  (enter  a  synopsis  of  the 

substantive  actions/issues) 

3 .  IT  Acquisition  Contract/Procurement  Status  Information: 

a.  Contractor  or  Source;  Award  Date  or  Date  of  Agreement; 
IT  acquisition  contract/procurement  duration:  (enter  contractor's 
name  or  the  source  for  the  acquisition  contracts/procurements 
that  do  not  involve  contracts;  award  or  agreement  date;  and  IT 
acquisition  contract/procurement  maximum  duration  (e.g.,  2  year 
base  period  and  three  1  year  options.) 

b.  Total  IT  cost  and  quantity:  (provide  the  estimated 

value  (including  all  possible  options) ,  number  of  units  planned 
and  purchased.) 

c.  Estimated  Usage  Value  and  quantity:  (provide  the 

estimated  value  of  the  dollars  expended  on  the  IT 
contract/procurement  and  the  quantity  delivered.) 

d.  External  interest:  (provide  a  brief  explanation) 

e.  Compliance: 

4.  Assessment :  (enter  a  one  or  two  paragraph  assessment  of  the 

progress  of  the  IT  acquisition  contract/procurement 
(unsatisfactory,  marginal,  or  satisfactory)  in  view  of  the 
substantive  action/issue.) 
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3 . 7  Human  Systems  Integration  and  Environment,  Safety,  and 

Occupational  Health  (ESOH)  Considerations 

PMs  of  IT  systems  should  evaluate  the  ESOH  requirements 
and  considerations  during  design,  development,  and 
installation/deployment  of  computer  software  and  hardware, 
including  the  incorporation  of  human  systems  integration  and 
ergonomics  considerations  per  references  (a)  and  (q) .  Software 
safety  risks  for  critical  control  and  display  systems  should  be 
evaluated  using  MIL-STD-8 82D .  As  with  other  systems 
acquisition,  demilitarization  and  disposal  planning  for  IT 
systems  should  include  ESOH  considerations  and  potential 
environmental  impacts. 
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Chapter  4 

Integrated  Test  and  Evaluation 


(a) 

DoD  Instruction  5000.02  of 

8  Dec  2008 

(b) 

DoD  Instruction  5010.41  of 

12  Sep  2005 

(c) 

SECNAVINST  5200.40 

(d) 

SECNAV  M-5510.36 

(e) 

CJCSI  6212. 01E 

(f) 

DoD  Instruction  8500.2  of  6 

Feb  2003 

(g) 

DoD  Instruction  8510.01  of 

28  Nov  2007 

(h) 

SECNAVINST  5239. 3B 

(i) 

OPNAVINST  2 4 00. 2  OF 

(j) 

OPNAVINST  5100. 24B 

(k) 

32  CFR  775 

(1) 

32  CFR  187 

(m) 

Assistant  Secretary  of  the 

Navy  (Installations 

and  Environment)  Memorandum 

i  99-01,  Requirements 

for  Environmental  Considerations  in  Test  Site 

Selection,  of  11  May  1999 

(n) 

OPNAVINST  5090. 1C 

(o) 

DoD  Instruction  4630.8  of  30  Jun  2004 

(p) 

SECNAVINST  5000. 36A 

(q) 

SECNAVINST  5100. 10 J 

(r) 

OPNAVINST  5100. 19E 

(s) 

OPNAVINST  5100. 23G 

(t) 

Director  Operational  Test  and  Evaluation 

Memorandum,  Procedures  for 

Operational  Test 

and 

Evaluation  for  Information 

Assurance  in 

Acquisition  Programs,  of  21 

Jan  2009 

(u) 

DoD  Directive  5230.20  of  22 

Jun  2005 

(V) 

OPNAVINST  9072.2 

(w) 

DoD  Instruction  3200.14  of 

13  May  1997  with 

Ch  3 

of  28  Jun  2001 


Chapter  4  Preamble 

This  chapter  has  been  organized  with  the  intent  to 
localize  as  much  test  and  evaluation  information  as  possible  for 
the  reader.  All  information  in  chapter  4  of  SECNAVINST  5000. 2E 
has  been  incorporated  into  this  chapter  of  the  guidebook.  The 
information  from  SECNAVINST  5000. 2E  is  annotated  within  brackets 
and  bold,  italicized  print.  SECNAVINST  5000. 2E  content  begins 
with  a  bracket,  the  italicized  from  SNI  5000 . 2E,  with  the 
appropriate  SECNAVINST  paragraph  number  followed  by  a  colon,  the 
content,  and  ends  with  a  bracket  (i.e.  [ from  SNI  5000. 2E,  4.1: 

text  content  from  instruction]).  References  letters  (a,  b,  etc.) 
from  SECNAVINST  5000. 2E  within  the  brackets  have  been  modified  as 
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necessary  to  track  to  the  correct  reference  at  the  beginning  of 
each  chapter.  Additional  guidance  and  supporting  information  is 
outside  the  brackets. 

4 . 1  Integrated  Test  and  Evaluation  (T&E)  Overview 

[ from  SNI  5000. 2E,  4.1:  T&E  is  conducted  continuously 
throughout  the  acquisition  life-cycle  of  a  system: 

a.  For  statutory  and  regulatory  reasons ;  and 

h.  To  gain  knowledge  that  can  be  used  to: 

(1)  Advance  system  development ; 

(2)  Make  programmatic  acquisition  decisions;  and 

(3)  Inform  users  about  the  system's  operational 
characteristics  and  performance. 

This  chapter  delineates  the  mandatory  T&E  roles , 
responsibilities ,  procedures ,  and  requirements  for  Department  of 
the  Navy  (DON)  acquisition  programs.  While  T&E  is  divided  into 
developmental  (contractor  and  government) ,  operational,  and  live 
fire  testing,  it  shall  be  integrated  and  coordinated  with  the 
users,  the  system  developers,  and  the  testers  to  the  fullest 
extent  allowed  by  statute  and  regulation .  The  integration  and 
coordination  of  T&E  shall  start  early,  preferably  during  materiel 
solution  analysis .  Where  mandatory  T&E  procedures  and 
requirements  are  not  provided  for  herein  or  need  clarification , 
guidance  shall  be  requested  for  Navy  programs  from  the  Chief  of 
Naval  Operations  (CNO) ,  Director  of  Innovation ,  Test  and 
Evaluation ,  and  Technology  Requirements  (N84) ,  or  for  Marine 
Corps  programs  from  the  Commander ,  Marine  Corps  Systems  Command 
(Commander,  MARCORSYSCOM)  for  developmental  test  and  evaluation 
CDT&E)  matters  and  Director ,  Marine  Corps  Test  and  Evaluation 
Activity  (MCOTEA)  for  operational  test  and  evaluation  (OT&E) 
matters . ] 

As  defined  in  Office  of  Secretary  of  Defense  Memorandum 
dated  25  April  2008:  "Integrated  testing  is  the  collaborative 
planning  and  collaborative  execution  of  test  phases  and  events  to 
provide  data  in  support  of  independent  analysis,  evaluation,  and 
reporting  by  all  stakeholders  particularly  the  developmental 
(both  contractor  and  government)  and  operational  test 
communities . " 
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Execution:  All  programs  should  establish  a  team  made  up 

of  all  relevant  organizations  (including  contractors, 
developmental  and  operational  test  communities)  to  create  and 
manage  an  integrated  T&E  strategy  that  will  be  incorporated  into 
the  Test  and  Evaluation  Master  Plan  (TEMP) .  The  team  is 
established  as  early  as  possible  in  the  program,  preferably 
during  the  materiel  solution  analysis  phase,  to  collaboratively 
identify  test  parameters,  data,  and  resources  required  for  the 
development  of  the  DT  and  OT  plans  and  other  required 
certifications  (i.e.,  interoperability,  system  assurance,  anti¬ 
tamper,  safety,  etc)  to  optimize  test  data  collection  while 
minimizing  test  resource  requirements.  The  intent  is  to  increase 
the  overall  efficiency  of  testing,  improve  product  performance, 
and  decrease  the  acquisition  timeline.  The  milestone  decision 
authority  (MDA)  should  provide  formal  direction  establishing  the 
test  team  in  the  program' s  acquisition  decision  memorandum  (ADM) . 
As  appropriate,  contractor  participation  in  the  integrated  test 
planning  and  execution  will  be  included  in  Requests  for  Proposals 
(RFPs)  and  subsequent  contracts.  Each  test  activity  is 
responsible  for  reporting  results  based  on  independent  analysis 
of  shared  data. 

The  test  requirements  of  this  chapter  should  be  tailored 
for  shipbuilding  programs  beyond  legacy  Milestone  II/low-rate 
initial  production  (LRIP) . 

4 . 2  DON  Points  of  Contact  and  Responsibilities  for  T&E 

[ from  SNI  5000. 2E,  4.2:  To  effect  an  efficient  forum  for 
collaboration ,  personnel  who  participate  in  T&E  processes  for  the 
DON  must  have  fundamental  knowledge  of  the  DoD  practice  of 
integrated  product  teams  (IPTs)  and  the  responsibilities  of 
organizations  contained  in  this  instruction .  The  responsibilities 
contained  herein  are  not  meant  to  be  restrictive  in  nature,  but 
to  provide  a  common  base  for  all  T&E  participants  to  communicate 
organization,  plans,  and  execution .  In  addition  to  understanding 
the  intent  of  T&E  guidance  provided  in  this  instruction ,  DON 
personnel  should  utilize  Web-enabled  knowledge  forums  to  amplify 
their  knowledge  of  standard  and  best  practices ,  lessoned  learned, 
and  to  ensure  compliance  with  legal  statutes  and  regulations.  DON 
personnel  shall  comply  with  reference  (a)  and  utilize  the  Defense 
Acquisition  Guidebook  and  SECNAV  M-5000.2  DON  Acquisition  and 
Capabilities  Guidebook  for  procedural  guidance .] 

4.2.1  Principal  Navy  Points  of  Contact  and  Responsibilities 

4. 2. 1.1  Chief  of  Naval  Operations  (CNO)  (N84) ,  Director 
Innovation,  Test  and  Evaluation,  and  Technology  Requirements 
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[from  SNI  5000.2E,  4. 2. 1.1:  CNO  (N84)  is  the  DON  T&E 
executive  reporting  to  Vice  Chief  of  Naval  Operations  (VCNO)  and 
Assistant  Commandant  of  the  Marine  Corps  (ACMC)  on  T&E  policy , 
requirements  and  resources  for  operational  testing,  and  to 
ASN (RD&A)  on  T&E  matters  pertaining  to  ASN (RD&A)  equities.  CNO 
(N84)  is  responsible  for  establishing  T&E  policy,  determining  the 
adequacy  of  T&E  infrastructure  required  to  support  systems 
testing,  coordinating  Navy  participation  in  joint  testing 
matters,  reviewing  capabilities  documents  (e.g.,  initial 
capabilities  document  (ICD) ,  capability  development  document  and 
capability  production  document  (CDD  and  CPD) )  for  testability, 
and  resolving  developmental,  live- fire ,  and  operational  test 
issues.  CNO  (N84)  shall  act  as  the  final  authority  and  signatory 
for  CNO  sponsored  test  and  evaluation  master  plans  (TEMPs)  prior 
to  component  acquisition  executive  (CAE)  approval  and  signature 
(see  table  E2T2  for  TEMP  approval  authority) .  CNO  (N84)  shall  be 
responsible  for  overseeing  testing  matters  associated  with  Marine 
Corps  aircraft ,  aviation  equipment,  and  air  traffic  control  and 
landing  (ATCAL)  equipment.] 

CNO  (N842)  action  officers  participate  in  T&E  working- 
level  integrated  product  teams  (T&E  WIPT)  (see  paragraph  4.4.3); 
and  when  necessary,  convene  a  test  and  evaluation  coordination 
group  (TECG)  as  discussed  in  paragraph  4.4.4. 

CNO  (N84)  is  also  responsible  for: 

a.  Coordinating  Fleet  assets  for  operational  test  and 
evaluation  (OT&E)  support  for  the  United  States  Marine  Corps 
(USMC) ; 


b.  Providing  principal  liaison  with  Commander, 

Operational  Test  and  Evaluation  Force  (COMOPTEVFOR)  on 
operational  test  requirements  and  execution; 

c.  Acting  for  CNO  as  the  single  point  of  contact  for 
interface  with  DoD's  Director,  Operational  Test  and  Evaluation 
(DOT&E)  for  all  T&E  policy  issues  and  all  matters  related  to  the 
test  and  evaluation  master  plan  (TEMP)  and  monitors  all 
operational  test  plan  coordination  and  approval; 

d.  Acting  for  CNO  as  the  single  point  of  contact  for 
interface  with  Deputy  Assistant  Secretary  of  Defense  for 
Developmental  Test  and  Evaluation  (DASD(DT&E))  office  for  all  T&E 
policy  issues  and  all  matters  regarding  TEMP  coordination  and 
approval ; 
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e.  Serving  as  the  Office  of  the  Chief  of  Naval  Operations 
(OPNAV)  point  of  contact  with  the  Office  of  the  Secretary  of 
Defense  (OSD)  on  Joint  Test  and  Evaluation  (JT&E)  Program 
conducted  per  reference  (b) ; 

f.  Serving  as  the  Navy  LFT&E  primary  point  of  contact; 

and 

g.  Serving  as  the  principal  interface  between  CNO  and 
Assistant  Secretary  of  the  Navy  (Research,  Development  and 
Acquisition)  (ASN (RD&A) ) ,  on  matters  relating  to  T&E. 

4. 2. 1.2  Program  Manager  (PM) 

[ from  SNI  5000.2E,  4. 2. 1.2:  The  PM  shall ,  in  concert  with 
the  developer,  user,  and  testing  communities ,  lead  DT&E)  and 
Live-Fire  Test  and  Evaluation  (LFT&E) ,  coordinate  OT&E,  family- 
of -systems  interoperability  testing,  information  assurance 
testing,  and  modeling  and  simulation  (M&S)  activity  into  an 
efficient  continuum,  closely  integrated  with  requirements 
definition,  integrated  system  design,  development,  production, 
and  sustainment ,  that  achieves  the  approved  capability .  The 
necessary  time  and  resources  shall  be  planned  and  budgeted  to 
ensure  adequate  testing  is  conducted  to  support  decision  makers 
and  the  Fleet  throughout  the  life-cycle  of  the  acquisition .  The 
PM  is  responsible  for  documentation  of  T&E  planning  in  the  test 
and  evaluation  strategy  (TES)  and  TEMP.  The  PM  shall  provide  for 
the  appropriate  safety  releases  per  reference  (j)  (to  include 
formal  environment,  safety,  and  occupational  health  (ESOH)  risk 
acceptance)  and  materiel  certifications  prior  to  any 
developmental  or  operational  tests  using  personnel  (see  paragraph 
4. 4.  7.  7).} 

The  PM  should  advise  the  decision  authority  that  the 
program  is  ready  for  operational  testing  and  initiate  an 
operational  test  readiness  review  (OTRR)  to  certify  the  program 
ready  for  the  next  phase  of  operational  evaluation.  See 
paragraphs  4.6.1  and  4.6.2  of  this  guidebook  for  details  on 
criteria  and  procedures  for  OTRRs . 

4. 2. 1.2.1  Personnel  Security  Clearances 

When  programs  involve  security  measures  that  require 
special  consideration  (i.e.  new  technologies,  anti-tamper. 

Special  Compartmented  Information  or  Access  Programs) ,  the  PM 
should  ensure  adequate  lead-time  is  provided  for  testing 
agencies,  in  particular  operational  test  agents,  to  identify 
subject  matter  experts  who  qualify  and  are  granted  access  to 
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information  that  will  allow  independent  preparation  for  T&E 
strategies  and  plans.  When  billets  are  limited  or  restricted, 
the  PM  is  responsible  for  coordinating  an  adequate  billet 
structure  to  support  testing. 

4. 2. 1.3  Commander,  Operational  Test  and  Evaluation  Force 
( COMOPTEVFOR) 

[ from  SNI  5000. 2E,  4. 2. 1.3:  COMOPTEVFOR  is  the  designated 
operational  test  agency  (OTA)  for  the  United  States  Navy  and  for 
Marine  Corps  aviation  programs  assigned  to  CNO  sponsorship . 
COMOPTEVFOR  shall:  plan ,  conduct ,  evaluate ,  and  report  the  OT&E 
of  acquisition  category  (ACAT)  I,  IA,  II,  III,  IVT ,  and  rapid 
deployment  capability  (RDC)  programs ;  monitor  ACAT  IVM  programs 
and  AAPs;  evaluate  initial  tactics  for  systems  that  undergo  OT&E; 
and  make  fleet  release  or  introduction  recommendations  to  CNO  for 
all  ACAT  programs  and  those  system  configuration  changes  selected 
for  OT&E.  COMOPTEVFOR  prepares  the  OT&E  content  and  a  listing  of 
test  resources  needed  to  execute  operational  test  for  the  TEMP. 
COMOPTEVFOR  shall  coordinate  for  multi -service  and  joint  OT&E, 
and  is  the  lead  OTA  when  the  Navy  is  assigned  lead.  COMOPTEVFOR 
is  the  designated  {research,  development,  test,  and  evaluation 
(added  in  this  guidebook  for  clarification) }  ( RDT&E )  fleet- 

support  scheduling  agent  for  CNO  (N84) . ] 

In  addition,  COMOPTEVFOR: 

a.  Serves  as  an  advisor  to  CNO  on  DON  matters  pertaining 
to  OT&E; 

b.  Coordinates  the  scheduling  of  resources  for  OT; 

c.  Identifies  significant  test  limitations  and  advises 
the  CNO  (N84),  other  CNO  codes  as  requested,  and  MDA  of  risk 
associated  in  the  procurement  decision; 

d.  Coordinates  Navy  support  of  other  military  Services' 

OT&E; 

e.  Assists  in  the  conduct  of  DT&E  monitoring  and 
commenting  on  relevant  OT&E  issues;  and 

f.  Ensures  that  operations  and  system  security 
requirements  are  met  for  all  OT&E  evolutions. 

g.  Reviews  and  advises  on  need  for  Quick  Reaction 
Assessments  to  support  Rapid  Development  and  Deployment  (RDD) 
systems.  The  OTA  is  responsible  for  providing  a  written 
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recommendation  to  the  RDD  authority  charged  with  test  planning. 
See  paragraphs  1.8.3.2c. (5)  and  4.7.5  of  SECNAVINST  5000. 2E. 

h.  Provides  written  concurrence  that  operational  testing 
is  not  required  for  ACAT  IVM  programs  and  Abbreviated  Acquisition 
Programs  (AAPs) .  See  paragraphs  1.4.5  and  1.4.6  of  SECNAVINST 
5000. 2E. 

4. 2. 1.4  Naval  Systems  Commands  (SYSCOMs) 

[ from  SNI  5000.2E,  4. 2. 1.4:  SYSCOMs  shall  manage  assigned 
infrastructure  (facilities ,  test  ranges,  land,  and  personnel)  to 
ensure  efficient  and  effective  DT&E  and  LFT&E  of  systems  within 
the  SYSCOM' s  domain.  When  requested  and  funded,  SYSCOMs  will 
support  programs  with  the  resources  needed  to  coordinate 
planning,  scheduling,  and  executing  T&E  throughout  the  continuum 
of  system  development .] 

4. 2. 1.4.1  Naval  Air  Systems  Command  (NAVAIRSYSCOM) 

[from  SNI  5000.2E,  4. 2. 1.4.1:  NAVAIRSYSCOM,  in  support  of 
PMs ,  shall  conduct  and  report  on  DT&E  and  LFT&E  of  Navy  and  CNO 
sponsored  Marine  Corps  aircraft ,  aviation  systems,  aircraft 
launch  and  recovery  equipment  (ALRE) ,  and  ATCAL  equipment.] 

4. 2. 1.4. 1.1  Naval  Air  Systems  Command  Technical 
Assurance  Board  (NTAB) 


The  NTAB  monitors  emerging  aircraft  and  aircraft-related 
programs  under  development.  All  aircraft  ACAT  I  naval  aviation 
programs  and  other  select  programs  when  requested  by  the 
developing  activity  (DA),  the  resource  sponsor,  or  CNO  (N84) 
should  be  monitored  until  completion  of  initial  operational  test 
and  evaluation  (IOT&E) .  Monitoring  should  continue  until  all 
major  deficiencies  are  resolved  or  the  program  is  removed  from 
the  major  defense  acquisition  program  (MDAP)  list. 

NAVAIR  INSTRUCTION  3960.5  provides  policies,  procedures, 
and  responsibilities  for  the  NTAB  monitoring  of  aircraft  weapon 
system  development.  In  addition,  NTAB  should: 

a.  Report  and  classify  deficiencies  as  NTAB  deficiencies 
according  to  COMNAVAIRSYSCOM  instructions  (Yellow  sheet  reporting 
instructions) . 

b.  In  the  event  that  NTAB  Part  I  deficiencies  are 
temporarily  waived  or  deferred  per  SECNAVINST  5000. 2E, 
chapter  4,  paragraph  4.6.4,  continue  monitoring  until 
commencement  of  first  deployment. 
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c.  Provide  subject  matter  expertise  in  T&E  WIPT  process. 

4. 2. 1.4. 2  Weapons  System  Explosive  Safety  Review  Board 

(WSESRB) 

[ from  SNI  5000.2E,  4. 2. 1.4. 2:  The  WSESRB  is  the  Navy's 
independent  oversight  agent  for  assessing  DON  weapons  programs' 
safety  compliance  efforts  associated  with  explosives ,  energetic 
systems ,  weapons,  combat  systems,  and  those  systems  that  manage 
and  control  weapons.  The  WSESRB  evaluates  the  applicable 
explosive  safety  criteria  and  environmental  requirements ,  and 
advises  the  responsible  Navy  and  Marine  Corps  commands,  MDAs , 

PEOs ,  and  PMs  on  the  adequacy  of  compliance .  The  WSERB  has  final 
decision  authority  over  the  explosive  safety  planning  for  the 
conduct  of  final  developmental  and  operational  testing  and 
overall  explosive  safety  compliance  for  major  acquisition 
decisions . ] 

NAVSEA  INSTRUCTION  8020. 6E  (Distribution  authorized  to  DoD 
and  DoD  contractors  only;  other  requests  must  be  referred  to 
COMNAVSEA  or  the  cognizant  NAVSEA  Code)  provides  membership, 
responsibilities  and  procedures  for  the  WSESRB.  DON  programs 
that  develop  or  utilize  energetic  elements  or  systems  that 
interface  with  energetic  systems  should  consult  with  the  WSESRB 
in  the  materiel  solution  analysis  phase  or  earlier. 

4. 2. 1.4. 3  Space  and  Naval  Warfare  Systems  Command 
(SPAWAR)  Office  of  the  Chief  Engineer  (CHENG) 

The  SPAWAR  CHENG  serves  as  the  principal  subject  matter 
expert  for  T&E  of  command,  control,  communications,  computers, 
intelligence,  surveillance,  and  reconnaissance  (C4ISR) ,  business 
IT,  and  space  systems  throughout  the  SPAWAR  domain.  This  office 
supports  the  T&E  WIPT  process  to  ensure  statutory,  regulatory, 
and  all  other  testing  objectives,  including  joint 
interoperability  and  other  certifications  are  accomplished.  The 
SPAWAR  CHENG  also  advises  decision  authorities  as  to  the 
resolution/status  of  these  objectives  before  major  program 
decisions . 

4. 2. 1.5  Farragut  Technical  Analysis  Center  (TAC) 

[ from  SNI  5000.2E,  4. 2. 1.5:  Farragut  TAC  is  the  designated 
naval  activity  responsible  for  threat  intelligence  and  validating 
threat  tactics  supporting  T&E  of  Navy  acquisition  programs. 

Threat  environments  for  T&E  of  ACAT  ID  programs  will  be  based  on 
a  system  threat  assessment  report  (STAR)  that  is  validated  by  the 
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Defense  Intelligence  Agency  (DIA)  per  reference  (a) .  T&E  for 
ACAT  IC  programs ,  or  programs  of  lesser  ACAT  on  OSD  T&E 
oversight ,  will  base  threat  scenarios  on  a  STAR  validated  by  the 
component.  T&E  for  ACAT  II  programs  require  a  system  threat 
assessment  (STA)  validated  by  the  component.  Reference  (a) 
identifies  threat  validation  requirements.] 

4.2.2  Principal  Marine  Corps  Points  of  Contact  and 
Responsibilities 

4. 2. 2.1  Deputy  Commandant  for  Manpower  and  Reserve  Affairs 
(DC,  M&RA) 

[ from  SNI  5000.2E,  4. 2. 2.1:  DC,  M&RA  assigns  personnel  per 
established  manpower  requirements  for  Marine  Corps  participation 
in  joint  test  and  evaluation  (JT&E)  and  in  support  of  OT&E  for 
ACAT  I  and  designated  ACAT  II  programs  within  manpower  guidelines 
established  by  the  Deputy  Commandant,  Combat  Development  and 
Integration  (DC,  CD&I)  and  after  consultation  with  Commander, 
MARCORSYSCOM  and  Director,  MCOTEA. 

DC,  M&RA  is  designated  the  functional  manager  for  Marine 
Corps  Manpower  Systems '  Automated  Information  Systems  (AISs) . 

DC,  M&RA  is  responsible  for  developing  the  concept  of  employment 
(COE)  and  mission  essential  (ME)  functions  for  manpower  AISs  and 
interoperability  and  standards  requirements  for  CDDs  and  CPDs . 

DC,  M&RA  will  provide  representatives  to  coordinate  with 
Commander,  MARCORSYSCOM ;  PEO  Land  Systems  (PEO-LS) ; and  Director, 
MCOTEA,  to  assist  in  determining  AIS  program  failure  definition 
(FD)  and  scoring  criteria  (SC)  for  each  manpower  system's  AIS 
program  under  development  and  provide  a  voting  member  for 
reliability,  availability ,  and  maintainability  (RAM)  scoring 
conferences . ] 

DC,  M&RA  assigns: 

a.  USMC  participants  in  joint  test  and  evaluation  (JT&E); 

b.  A  test  director  (TD)  for  OT&E  of  ACAT  I  and  designated 
ACAT  II  programs; 

c.  A  Deputy  TD  for  multi-service  OT&E  of  ACAT  I  programs; 

and 

d.  A  Deputy  TD  for  JT&E-approved  programs  as  appropriate. 

When  the  required  structure  for  items  b.,  c.,  and  d.  above 
is  not  on  the  joint  duty  assignment  list  ( JDAL) ,  a  compensated 
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structure  validation  should  be  completed  through  MCCDC  (Total 
Force  Structure  Division  (TFSD) )  and  the  Joint  Staff. 

4. 2. 2. 2  Deputy  Commandant  for  Installations  and  Logistics 
(DC,  I&L) 

[from  SNI  5000. 2E,  4. 2. 2. 2:  DC,  I&L  is  designated  the 
functional  manager  for  Marine  Corps  Logistics  Systems'  AISs.] 

DC,  I&L  is  responsible  for: 

a.  Developing  the  COE  and  mission  essential  functions  for 
Logistics  AISs  and  interoperability  and  standards  requirements 
for  CDDs  and  CPDs; 

b.  Providing  a  representative  to  coordinate  with 
Commander,  MARCORSYSCOM,  the  Marine  Corps  DRPMs,  and  Director, 
MCOTEA,  in  determining  AIS  program  FD  and  SC  for  each  Logistics 
System's  AIS  program  under  development;  and 

c.  Providing  a  voting  member  for  scoring  conferences. 

4. 2. 2. 3  Director,  Marine  Corps  Intelligence  Activity 

(MCIA) 


[ from  SNI  5000. 2E,  4. 2. 2. 3:  Director,  MCIA  shall  provide  a 
threat  test  support  package  (TTSP)  based  on  the  latest  STA  to 
Commander,  MARCORSYSCOM;  PEO-LS;  and  Director,  MCOTEA.  The  TTSP 
should  include  all  threat  data  required  to  support  DT,  OT  and 
LFT&E.  ] 


4. 2. 2. 4  Deputy  Commandant,  Combat  Development  and 
Integration  (DC,  CD&I) 

[ from  SNI  5000.2E,  4. 2. 2. 4:  DC,  CD&I  shall  develop  the 
concept  of  employment  (COE) ,  operational  mode  summary  and  mission 
profiles  (OMS  and  MP) ,  and  mission  essential  functions  for 
proposed  non-automated  information  systems  and  interoperability 
and  standards  requirements  for  CDDs  and  CPDs.  In  coordination 
with  the  material  developer  and  Director ,  MCOTEA,  provide  a 
representative  to  assist  in  determining  non- AIS  program  FD  and  SC 
for  each  program  under  development  and  provide  a  voting  member 
for  scoring  conferences . 

DC,  CD&I  provides  oversight  of  JT&E  for  the  Commandant  of 
the  Marine  Corps  (CMC)  and  Headquarters  Marine  Corps  (HQMC)  staff 
to  ensure  T&E  activities  directly  support  the  CMC ' s 
responsibilities  for  sustained  material  readiness  and  mission 
capability  of  the  Marine  operating  forces. 
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When  required ,  DC,  CD&I  shall  act  on  OT&E  deferral  and 
waiver  requests  for  Marine  Corps  ground  systems  as  outlined  in 
paragraph  4.6  below.] 

4. 2. 2. 5  Commander,  Marine  Corps  Systems  Command 
(Commander,  MARCORSYSCOM)  and  Program  Executive  Office  for  Land 
Systems  (PEO-LS) 

[ from  SNI  5000.2E,  4. 2. 2. 5:  Commander,  MARCORSYSCOM 
provides  oversight  of  programming  activities  related  to  T&E  for 
the  CMC  and  HQMC  staff  to  ensure  T&E  activities  directly  support 
the  CMC ' s  responsibilities  for  sustained  material  readiness  and 
mission  capability  of  the  Marine  operating  forces.  Commander, 
MARCORSYSCOM  and  PEO-LS  PM  shall  provide  a  test  support  package 
(TSP)  to  the  Director,  MCOTEA,  at  least  1  year  before  scheduled 
OT  start.  The  TSP  should  include,  at  a  minimum,  early  T&E,  a  CDD 
and  CPD,  a  STA,  a  threat  scenario ,  a  DC,  CD&I-approved  COE, 
program  documentation  addressing  support  and  life-cycle 
management  of  hardware  and  computer  resources ,  and  an 
organizational  structure  to  include  a  table  of  organization  and 
table  of  equipment.  Upon  request,  the  PM  should  provide  software 
documentation.  MCIA  provides  the  STA  no  later  than  milestone  A. 

Commander ,  MARCORSYSCOM  serves  as  the  Marine  Corps  point 
of  contact  with  Office  of  the  Secretary  of  Defense  (OSD)  on 
matters  relating  to  LFT&E. 

Commander ,  MARCORSYSCOM  shall  consolidate  and  process 
quarterly  requests  for  use  of  naval  fleet  assets  in  support  of 
RDT&E  requirements. 

Commander ,  MARCORSYSCOM  shall  represent  the  Marine  Corps 
in  all  DT&E  matters. 

Commander ,  MARCORSYSCOM  or  PEO-LS  shall  be  the  primary 
interface  with  Joint  Interoperability  Test  Command  (JITC)  on 
joint  interoperability  testing  conducted  during  DT . 

Commander ,  MARCORSYSCOM  or  PEO-LS  shall  exercise  review 
and  approval  authority  over  TEMPs  for  assigned  programs  and 
mul ti -servi ce  programs . 

Commander,  MARCORSYSCOM  or  PEO-LS  shall  establish  and 
chair  a  test  and  evaluation  working  integrated  product  team  (T&E 
WIPT)  for  all  assigned  programs. 
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Commander ,  MARCORSYSCOM  or  PEO-LS  shall  certify  that 
systems  are  safe  and  ready  for  DT&E. 

Commander ,  MARCORSYSCOM  shall  manage  the  Marine  Corps 
External  Airlift  Transportation  (EAT)  Certification  Program  and 
the  Marine  Corps  Foreign  Comparative  Testing  Program. ] 

4. 2. 2. 6  Director,  Marine  Corps  Operational  Test  and 
Evaluation  Activity  (MCOTEA) 

[ from  SNI  5000. 2E,  4. 2. 2.  6:  MCOTEA  is  the  designated  OTA 
for  the  United  States  Marine  Corps.  Director ,  MCOTEA  shall 
ensure  that  the  operational  testing  and  evaluation  of  all  ACAT 
programs  is  effectively  planned ,  conducted,  and  reported;  and 
shall  coordinate  the  scheduling  of  resources  for  OT  requiring 
Marine  operating  forces  support  through  Marine  Forces 
Synchronization  Conferences  and  the  Two  Year  Master  Test  Plan 
(TYMTP)  published  annually  with  quarterly  updates. 

Director ,  MCOTEA  shall  host  and  chair  a  FD  and  SC  charter 
development  conference  for  the  development  of  an  FD  and  SC 
charter  for  each  program. 

Director ,  MCOTEA  shall  prepare  the  operational  test 
content,  with  the  exception  of  LFT&E,  and  a  listing  of  resources 
required  to  execute  operational  test  for  input  into  the  TEMP. 

Director ,  MCOTEA  shall  request,  from  the  office  of  ACMC , 
the  assignment  of  a  test  director  (TD)  for  ACAT  I  and  certain 
ACAT  II  programs  and  shall  coordinate  with  the  Marine  operating 
forces  and  other  commands  in  matters  related  to  OT&E  by 
publishing  a  test  planning  document  (TPD) . 

Director ,  MCOTEA  shall  manage  those  joint  OSD-directed 
multi -service  OT&Es  for  which  the  Marine  Corps  is  tasked  and 
coordinate  Marine  Corps  support  for  other  military  Services' 
OT&Es . 


Director ,  MCOTEA  shall  prepare  and  provide  directly  to  the 
ACMC,  within  90  days  (or  as  stipulated  in  the  TEMP)  after 
completion  of  OT&E,  an  OTA  evaluation  report  for  the  system  under 
test. 


Director ,  MCOTEA  shall  advise  the  ACMC  on  OT&E  matters. 
When  significant  limitations  are  identified  during  operational 
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evaluation ,  the  Director,  MCOTEA,  shall  advise  the  MDA  of  risk 
associated  in  the  procurement  decision . 

Director ,  MCOTEA  shall  maintain  direct  liaison  with  OSD's 
Director  of  Operational  Test  and  Evaluation  (DOT&E) ,  the  Marine 
operating  forces  for  OT&E  matters ,  and  other  military  activities 
and  commands,  as  required. 

Director ,  MCOTEA  shall  represent  the  Marine  Corps  in  all 
multi-service  OT&E  matters. 

Director ,  MCOTEA  shall  be  the  primary  interface  with  JITC 
on  joint  interoperability  testing  conducted  during  OT. 

For  USMC  programs  not  required  by  statute  to  conduct 
LFT&E,  but  where  LFT&E  is  appropriate ,  the  Director ,  MCOTEA  shall 
concur  with  the  LFT&E  strategy  as  approved  by  the  MDA  in  the  TES 
or  TEMP . ] 

4. 2. 2. 7  Marine  Operating  Forces 

[ from  SNI  5000 . 2E,  4.2.2.  7 ;  The  Commanding  Generals , 

Marine  Forces  Pacific  (MARFORPAC)  and  Marine  Forces  Command 
(MARFORCOM)  shall  designate  a  test  coordinator  as  a  focal  point 
for  all  T&E  matters  and  support  MCOTEA  in  the  T&E  of  new 
concepts,  equipment,  and  systems.  The  Marine  operating  forces 
shall  provide  a  Marine  operating  forces  officer  in  charge  (OIC) 
for  test  who  will  lead  the  Marine  operating  forces  participating 
in  the  operational  test  and  be  available  to  the  MCOTEA  evaluation 
team  for  at  least  30  days  after  completion  of  OT&E.  The  Marine 
operating  forces  shall  provide  personnel  and  equipment  to 
participate  in  JT&E  programs ,  as  required. ] 

4.2.3  Acquisition  Items  Exempt  from  T&E  Provisions  within 
this  Instruction  (SECNAVINST  5000 .2E) 

4. 2. 3.1  Items  Exempt 

[ from  SNI  5000. 2E,  4. 2. 3.1:  The  following  items  are  tested 
by  other  organizations  and  are  exempt  from  the  T&E  provisions  of 
this  instruction  (SNI  5000. 2E): 

a.  Cryptographic  or  cryptology  equipment; 

b.  Naval  nuclear  reactors  and  associated  systems ; 

c.  Nuclear  weapons  and  strategic  weapons  system 
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components ; 

d.  Medical  and  dental  systems;  and 

e.  Spacecraft  and  space-based  systems .] 

4. 2. 3. 2  T&E  Considerations  that  Apply  to  Exempt  Items 

[ from  SNI  5000.2E,  4. 2. 3. 2:  The  exemption  herein  does  not 
apply  to  the  following  aspects  of  these  items: 

a.  Information  technology  (IT)  administrative  systems ; 

b.  Ships  or  aircraft  that  carry  these  systems ; 

c.  Other  systems  that  these  exempt  items  support ;  and 

d.  Testing  conducted  at  the  request  of  or  in  cooperation 
with  above  parent  organizations . 

When  the  performance  of  these  exempted  items  affects  the 
effectiveness ,  suitability ,  survivability ,  or  lethality  of  a 
system  not  exempt  (e.g.,  communications  system  with  embedded 
cryptology  subsystem,  ship  with  nuclear  propulsion) ,  then  the 
exempted  item's  performance  may  be  considered  in  the  T&E  of  the 
supported  system.  Such  performance  assessments  must  be 
coordinated  with  and  approved  by  the  organization  with  direct 
responsibility  for  the  exempted  item  (e.g.,  National  Security 
Agency  (NSA)  for  cryptology  systems  or  naval  reactors  for  naval 
nuclear  propulsion  systems) . ] 

4 . 3  T&E  Strategy 

4.3.1  Preparation  and  Milestones 

[ from  SNI  5000. 2E,  4.3.1:  See  reference  (a),  enclosure  6, 
for  guidance  in  preparing  a  T&E  strategy  (TES)  that  is  required 
at  milestone  A.  The  TES  documents  a  strategy  of  realistic  T&E 
concepts  that  support  development  decisions  throughout  the 
acquisition  life-cycle .  The  TES  must  include  a  test  plan  that 
addresses  the  technology  development  phase,  a  description  of  the 
overall  approach  for  integrating  developmental,  operational  and 
live  fire  testing,  the  T&E  aspects  of  competitive  prototyping, 
and  the  early  demonstration  of  technologies  in  relevant 
environments  with  adequate  detail  to  construct  and  evaluate  pre¬ 
milestone  B  assessments  and  tests.  The  TES  is  the  precursor  to 
the  TEMP  that  is  required  for  milestone  B  and  beyond.  While 
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specific  program  alternatives  are  generally  unknown  before 
milestone  B,  the  TES  needs  to  address:  the  maturity  level  of  the 
technology;  anticipated  DT&E,  OT&E,  and  LFT&E  concepts;  and  early 
predictions  of  T&E  support  requirements  that  may  need  development 
or  procurement.  When  M&S  is  part  of  the  TES,  the  M&S  proponent 
shall  provide  the  strategy  to  comply  with  verification , 
validation  and  accreditation  (W&V)  per  reference  (c)  .  For  OT&E 
events  prior  to  milestone  B,  the  T&E  strategy  shall  identify 
objectives ,  scope,  and  funding,  as  well  as  overall  evaluation 
strategy .  Programs  shall  conform  to  OSD  policies  and  guidelines 
when  preparing  TES  documentation ,  unless  granted  relief  by  the 
TEMP  approval  authority . ] 

4.3.2  Strategy  Approval 

[ from  SNI  5000.2E,  4.3.2:  The  T&E  strategies  for  programs 
on  the  OSD  T&E  oversight  list  require  the  approval  of  DOT&E  and 
the  Director ,  Developmental  Test  and  Evaluation.  Programs  on  the 
OSD  T&E  oversight  list  will  prepare  a  T&E  strategy  and  coordinate 
with  CNO  (N84)  or  Director ,  MCOTEA  for  submission  via  the  same 
approval  process  for  a  TEMP. ] 

For  TES  signatures,  see  paragraph  4.4.7.13  of  this 
guidebook  for  routing  the  TEMP  for  approval  and  annex  4 -A  for  the 
signature  cover  pages  associated  with  the  appropriate  ACAT  level 
program . 

4 . 4  T&E  Planning 

4.4.1  Early  Planning  for  Integrated  T&E 

[from  SNI  5000. 2E,  4.4.1:  T&E  expertise  must  be  brought  to 
bear  at  the  beginning  of  the  system  life  cycle  to  provide  early 
learning  and  early  identification  of  technical ,  operational  and 
system  deficiencies.  This  ensures  that  appropriate  and  timely 
corrective  actions  can  be  developed  prior  to  system  fielding . 
Early  involvement  by  test  agencies  is  required  to  ensure 
successful  execution  of  integrated  testing  and  sharing  of  all 
appropriate  test  results  in  the  overall  system  evaluation.  The 
developing  activity  (DA) ,  test  agencies ,  and  user  representative 
and  resource  sponsor  must  share  a  common  interpretation  of  the 
system  capability  needs  so  that  DT  and  OT  are  tailored  to 
optimize  resources ,  test  scope,  and  schedule.  Early,  active,  and 
continuous  participation  by  test  agencies  during  the  development 
of  capabilities  documents  will  support  effective  communication 
and  common  interpretation.] 
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4. 4. 1.1  Early  Planning  Requirements 

[from  SNI  5000. 2E,  4. 4. 1.1:  Test  planning  requires  a 
coherent  evaluation  plan  that  aligns  with  the  Systems  Engineering 
Plan  (SEP) ,  acquisition  strategy,  and  CDDs  and  must  consider 
appropriate  measures  needed  to  support  the  RAM  growth  plan  and 
the  operational  environment  for  which  the  system  is  being 
developed.  Reference  (a)  requires  the  evaluation  include  a 
comparison  with  current  mission  capabilities  using  existing  data, 
so  that  measurable  improvements  can  be  determined.  If  such 
evaluation  is  considered  costly  relative  to  the  benefit  gained, 
the  PM  shall  propose  an  alternative  evaluation  approach.  This 
alternative  approach  shall  be  introduced  to  the  OTA  and  vetted 
through  the  TEMP  stakeholders  as  early  as  possible ,  but  no  later 
than  6  months  prior  to  TEMP  approval  due  date.] 

a.  See  the  Office  of  Deputy  Assistant  Secretary  of 
Defense  (Systems  Engineering)  (ODASD(SE))  SYSTEMS  ENGINEERING 
PLAN  (SEP)  OUTLINE,  dated  20  Apr  2011,  to  assess  test 
requirements  for:  technical  certifications;  schedules  reflect 
adequate  time  for  analysis,  corrective  action,  and  contingencies; 
Test  Lead  position  in  organizational  structure;  dependencies 
within  SoS  or  FoS;  synchronization  of  technical  reviews;  how  test 
results  will  inform  on  KPPs/KSAs;  and  the  reliability  growth 
plan . 


b.  Reliability  Growth  Curves  will  be  copied  from  the  SEP 
into  the  TEMP.  The  test  team  will  need  to  collaborate  with 
reliability  engineers  and  the  logistics  planners  on  test  measures 
required,  their  definitions,  and  timeframes,  as  well  as,  test 
strategies  and  methodologies  (e.g.  test-analyze-f ix-test  (TAFT), 
etc.)  for  growing  reliability. 

c.  To  support  the  DOD  mandated  requirement  to  complete  an 
evaluation  that  compares  current  mission  capabilities  with  the 
system  in  acquisition,  the  preferred  methodology  within  DON,  over 
side  by  side  test  events,  is  to  utilize  available  data  from 
previous  testing  or  comparable  field  information.  It  is 
essential  for  the  test  team  to  execute  as  early  as  possible  a 
thorough  review  of  all  sources  of  data  and  consider  the  best, 
most  cost  efficient  method  of  resourcing  comparison  evaluation 
requirements.  For  evolutionary  acquisitions,  test  teams  must 
ensure  they  are  generating  and  maintaining  data  that  will  be 
useful  for  future  incremental  comparisons. 

4.4.2  Testing  Increments  in  Evolutionary  Acquisition 

( from  SNI  5000.2E,  4.4.2:  Developing  agencies  shall  ensure 
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adequate  DT&E,  OT&E,  and  LFT&E  are  planned ,  funded ,  and  executed 
for  each  new  increment  capability ,  as  required.  The  PM  shall 
ensure  an  independent  phase  of  OT&E  prior  to  release  of  each 
increment  to  the  user.  Potentially  short  cycle  times  between 
milestone  decisions  necessitate  early  collaboration  between  the 
OTA,  JITC,  test  resource  providers  (labs,  ranges,  instrumentation 
sources,  etc.),  sponsors,  requirements  officers,  and  oversight 
agencies  in  test  planning  for  efficiency  and  testability  that 
effectively  evaluates  system  capabilities  and  performance  against 
earlier  increments  to  assess  increased  mission  capability  and 
determination  if  previous  capabilities  incurred  any  degradation. 
In  addition  to  integrating  test  events  to  the  fullest  extent 
within  statute  and  regulation ,  planners  shall  consider  parallel 
development  and  review  of  the  TEMP  and  the  relevant  capabilities 
documents  (e.g.,  ODD  and  CPD)  .] 

4. 4. 2.1  Innovative  Testing 

[from  SNI  5000. 2E,  4. 4. 2.1:  Short  incremental  development 
cycle  times  and  simultaneous  testing  of  multiple  increments  may 
require  innovative  methods  not  discussed  in  this  or  other 
acquisition  documents .  Innovative  or  irregular  methods  will  be 
described  within  the  appropriate  sections  of  the  TEMP.  TEMP 
concurrence  and  approval  will  formalize  the  agreement  to 
implement  those  methods  for  use  in  the  program. ] 

4. 4. 2. 2  Initial  Operational  Test  and  Evaluation  (IOT&E) 

[ from  SNI  5000.2E,  4. 4. 2. 2:  The  PM  shall  ensure  IOT&E  is 
completed  prior  to  proceeding  beyond  low  rate  initial  production 
(LRIP)  for  ACAT  I  and  II  programs  as  required  by  section  2399  of 
title  10  U.S.C.,  and  for  all  other  programs  on  the  OSD  T&E 
oversight  list  as  required  by  reference  (a) .  The  PM  shall  ensure 
OT&E  is  conducted  for  each  evolutionary  acquisition  increment  for 
programs  requiring  OT&E.  Following  consultation  with  the  PM, 
DOT&E,  for  programs  on  the  OSD  T&E  oversight  list,  or  the  OTA, 
for  programs  not  on  the  OSD  T&E  oversight  list,  shall  determine 
the  number  of  production  or  production-representative  test 
articles  required  for  IOT&E.  To  efficiently  resource  OT&E 
requirements ,  the  OTA  shall  plan  to  leverage  all  operationally 
relevant  T&E  data  and  provide  the  PM  with  an  early  projection  as 
to  OT&E  scope  and  resource  requirements.  See  reference  (a), 
enclosure  6,  for  implementation  requirements  for  DON  ACAT 
programs . ] 

IOT&E  is  defined  as  dedicated  operational  test  and 
evaluation  conducted  on  production,  or  production  representative 
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articles,  to  determine  whether  systems  are  operationally 
effective  and  suitable,  and  which  supports  the  decision  to 
proceed  beyond  LRIP.  (Defined  in  Defense  Acquisition  University 
Glossary  of  Terms  that  can  be  located  at 
https : //akss . dau .mil/ j  sp/ glossary.pdf) 

Traditionally,  Navy  programs  identified  this  phase  of  OT&E 
as  OPEVAL. 

OT&E  is  covered  in  this  guidebook,  chapter  4,  paragraph 

4.7. 

4. 4. 2. 3  Software  Intensive  Systems 

[ from  SNI  5000. 2E,  4. 4. 2. 3:  The  OTAs  are  encouraged  to  use 
DOT&E  best  practice  guidance  for  testing  software  intensive 
system  increments  (command,  control,  communications,  computers, 
intelligence ,  surveillance ,  and  reconnaissance  (C4ISR)  and  Major 
Automated  Information  System  (MAIS)  systems)  in  evolutionary 
acquisition .  Although  the  process  is  discretionary,  it 
effectively  defines  the  scope  and  level  of  testing  based  on 
potential  risk  to  mission  areas,  overall  system  complexity,  and 
the  complexity  of  changes  in  functionality  within  each  increment. 
Innovative  approaches  are  encouraged,  but  require  coordination 
with  oversight  agencies  to  ensure  adequacy  of  testing. 

Due  to  the  dynamic  nature  of  IT  programs ,  the  JROC  created 
the  "IT  Box"  approach  to  JCIDS  as  described  in  chapter  1 
(paragraph  1.1. 2. 3).  This  approach  applies  to  systems  where 
there  is  no  need  to  develop  hardware  systems  (i.e.,  they  use 
commercial  off-the-shelf  hardware,  or  already  developed  hardware) 
and  research  and  development  (R&D)  funding  is  spent  solely  on 
software  development.  Implementation  of  the  above  approach  may 
be  used  for  preplanned  series  of  software  developments  and/or 
hardware  refreshment,  including  programs  executing  advanced 
capability  builds  (ACB)  ,  advance  processing  builds  (APB)  ,  or 
technology  insertions  (TI) .  The  "IT  Box"  is  meant  to  lighten  the 
burden  of  JCIDS  as  the  program  progresses  through  system 
enhancement  within  the  parameters  defined  in  the  program's  CDD. 

It  ensures  both  the  planning  and  flexibility  are  in  place  to 
incorporate  evolving  technologies  over  the  lifecycle  of  a 
program.  Test  planning  shall  align  with  Navy  implementation 
described  in  chapter  1,  utilizing  risk  assessment  for  level  of 
test  required. ] 

This  best  practice  decision  process  for  software  intensive 
systems  is  described  in  this  guidebook,  paragraph  4. 7. 2. 2. 1.1  and 
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by  Director  Operational  Test  and  Evaluation  Memorandum, 

Guidelines  for  Operational  Test  and  Evaluation  of  Information  and 

Business  Systems,  of  14  Sep  2010 

<https : / / extranet .dote.osd.mil/policy. html> . 


4. 4. 2. 4  T&E  of  Ships 

Criteria  for  configuration,  functionality,  and  engineering 
changes  to  the  basic  ship  profile  should  be  defined  in  the  TES 
for  a  ship  program.  These  criteria  should  be  used  to  determine 
level  and  scope  of  T&E  required  for  increments  of  the  lead  ship 
as  well  as  follow  ships.  Approval  of  the  TES  and  subsequent 
TEMPs  should  establish  T&E  requirements  for  ship  and  ship  systems 
increments.  Should  the  T&E  WIPT  not  resolve  issues,  a  TECG 
chaired  by  CNO  (N84)  will  determine  when  a  new  ship,  ship  system 
or  increment  requires  full  ship  OT&E. 

DT&E  and  OT&E  prior  to  Milestone  B  should  normally  address 
T&E  of  individual,  new,  or  modified  shipboard  systems. 

Individual  weapon  system's  T&E  should  utilize  land-based  test 
sites  (LBTSs)  to  the  greatest  extent  possible.  For  prototype  or 
lead  ship  acquisition  programs,  T&E  should  be  conducted  on  the 
prototype  or  lead  ship  as  well  as  on  individual  systems. 

4. 4. 2. 4.1  Ship  Programs  Without  New  Development 

For  ship  programs  not  requiring  OT&E,  TEMP  requirements 
may  be  satisfied  by  performance  standards  within  the  shipyard 
test  program,  as  well  as  builder's  trials,  acceptance  trials,  and 
final  contract  trials,  specified  in  the  contract  and  in 
specifications  invoked  on  the  shipbuilder.  Representatives  of 
the  cognizant  PEO  and  DRPM  or  Naval  Sea  Systems  Command 
(NAVSEASYSCOM)  shipbuilding  program  office,  the  Supervisor  of 
Shipbuilding  for  the  respective  shipyard,  and  the  Board  of 
Inspection  and  Survey  (INSURV)  normally  observe  the  foregoing 
trials . 


4. 4. 2. 5  T&E  of  Space  Systems 

As  stated  in  paragraph  4.2.3  of  SECNAVINST  5000. 2E,  Space 
systems  are  exempt  from  T&E  requirements  contained  herein.  Policy 
and  approach  for  T&E  of  Space  Systems  is  contained  in  USD (AT&L) 
Directive-Type  Memorandum  (DTM)  09-025,  Space  Systems  Acquisition 
Policy  (SSAP) ,  of  18  Oct  2010 

<http : / /www. dtic .mil /whs/ directives/ cor res /pdf /DTM- 09-02 5 .pdf> . 


4.4.3  Test  and  Evaluation  Working  Integrated  Product  Team 
(T&E  WIPT) 
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[from  SNI  5000. 2E,  4.4.3:  The  T&E  WIPT  is  a  DoD  and  DON 
wide  accepted  forum  for  representatives  from  across  program 
disciplines  and  oversight  agencies  to  discuss ,  coordinate,  and 
resolve  T&E  planning  goals  and  issues.  The  PM,  or  designated 
representative  (normally  military  0-6/0-5  or  civilian 
equivalent) ,  is  responsible  for  initiating  (early  in  the  life  of 
the  program,  preferably  before  milestone  A)  and  chairing  the  T&E 
WIPT.  ] 

All  participants  in  a  T&E  WIPT  should  be  familiar  with  the 
USD  (AT&L)  publication.  Rules  of  the  Road:  A  Guide  for  Leading 
Successful  Integrated  Product  Teams,  that  may  be  found  at: 
https : // acc . dau .mil/ CommunityBrowser . aspx?id=24459 

Error!  Hyperlink  reference  not  valid. 

The  following  composition,  responsibilities,  and  practices 
comprise  the  general  business  of  a  T&E  WIPT: 

a.  Recommended  core  membership  (should  be  invited) : 

(1)  DA  T&E  IPT  Lead  is  Chair; 


(2)  Sponsor  Requirements  Officer  (RO) ; 

(3)  OTA  Operational  Test  Coordinator ( s )  (OTC)  and  the 
Operational  Test  Director (s)  (OTD) ; 


(4)  Program  Office  DT&E  representative ( s ) ; 

(5)  Contractor  T&E  representative (s); 


JITC, 


(6)  Representative ( s )  from  certifying  agencies 
WSESRB,  NTAB,  etc.)  as  appropriate; 


(e.g. , 


(7)  OPNAV  T&E  (N84)  Action  Officer; 


list; 


(8)  DOT&E  representative ( s )  when  on  OSD  T&E  oversight 


(9)  When  on  OSD  T&E  oversight  for  DT,  a  representative 
from  the  Deputy  Assistant  Secretary  of  Defense  for  Developmental 
Test  and  Evaluation  (DASD(DT&E))  in  the  Office  of  Assistant 
Secretary  of  Defense  (Research  and  Engineering)  within  the  Office 
of  the  Under  Secretary  of  Defense  for  Acquisition,  Technology  and 
Logistics  (OUSD (AT&L) ) ; 


(10)  Program  Executive  Office  (PEO)  representative; 


(11)  ASN (RD&A) ,  appropriate  DASN  representative,  and 
additional  membership  recommended  for  invitation; 
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(12)  ONI  Threat  Analysis  representative ( s ) ; 

(13)  OPNAV  Education  and  Training  (N15)  Action 

Officer; 

(14)  SYSCOM  T&E  representative ( s ) ; 

(15)  Test  laboratories,  facilities,  and  engineering 
subject  matter  expertise  as  needed;  and 

(16)  Principal  for  Safety  and  ESOH  Manager 
representatives . 

b.  Based  on  the  acquisition  strategy  and  the  program's 
proposed  test  strategy  and  concepts,  the  T&E  WIPT  should  support 
the  PM  through  review  and  discussion  that  offers  subject  matter 
expertise  and  policy  guidance  that  seeks  the  most  economical  and 
effective  T&E  strategy  and  plans.  Representatives  should  have 
sound  subject  matter  expertise  and  authority  to  speak  for  their 
agency . 


c.  A  T&E  WIPT  should  be  formed  in  the  early  materiel 
solution  analysis  phase  to  begin  a  review  of  T&E  strategy  and  lay 
plans  for  fully  integrating  the  T&E  effort. 

d.  Meeting  agenda,  minutes,  and  draft  TEMPs  should  be 
maintained  and  distributed  to  all  members  as  early  as  possible. 
Establishment  of  web-based  forums  is  highly  recommended.  T&E 
WIPT  leaders  should  be  aware  that  key  policy  representatives  are 
routinely  members  of  several  dozen,  and  in  some  cases  hundreds, 
of  programs,  so  it  is  essential  to  manage  meeting  schedules  and 
distribution  of  information  in  forums  that  keep  everyone  well 
informed . 

e.  Sub-groups  should  be  considered  for  various  test 
phases  and  action  items  to  keep  subject  matter  expertise  and 
agenda  focused.  All  minutes  and  draft  documents  from  these 
groups  should  be  distributed  to  the  membership.  Sub-groups 
should  be  referred  to  as  test  plan  working  groups  (TPWGs)  for 
specific  phase  or  action  to  efficiently  direct  communication  and 
documentation . 

4.4.4  Navy  Test  and  Evaluation  Coordination  Group  (TECG) 

[ from  SNI  5000. 2E,  4.4.4:  When  T&E  issues  arise  that 
cannot  be  resolved  by  the  T&E  WIPT,  a  TECG  should  be  convened.  A 
TECG  may  also  be  used  to  implement  urgent  required  changes  to  the 
TEMP.  When  used  for  urgent  TEMP  changes  either  a  page  change 
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should  be  issued  or  the  formal  report  of  the  TECG  should  be 
attached  to  the  TEMP  as  an  annex  until  the  next  required  update 
or  revision .  When  an  activity  determines  a  more  formal  solution 
is  required  to  resolve  an  issue,  the  activity  --  via  formal 
correspondence  —  will  request  that  CNO  (N84)  or  DC,  CD&I ,  as  the 
responsible  authority  for  T&E  issue  resolution ,  convene  a  TECG. 
For  programs  on  the  OSD  T&E  oversight  list,  the  TECG  chair,  CNO 
(N84)  or  DC,  CD&I  shall  coordinate  results  with  DOT&E  and 
USD  (AT&L)  .  ] 


4. 4. 4.1  TECG  Membership 

When  T&E  issues  require  resolution,  CNO  (N842)  coordinates 
the  appropriate  level  of  chair  authority  and  convenes  the  TECG 
via  formal  correspondence  with  membership  from: 

a.  CNO  (N84)  or  (N842)  Director  Test  and  Evaluation 
Division  -  Chair 

b.  CNO  (N842)  T&E  staff  action  officer 

c.  Sponsor  requirements  officer  (user  representative) 

d.  Proqram  manaqer 

e.  COMOPTEVFOR  Assistant  Chief  of  Staff  (ACOS)  for  the 
particular  warfare  division,  and/or  Director,  MCOTEA  Division 
Lead  (as  applicable) 


f.  Applicable  ASN (RD&A)  program  staff 

q.  DASN (RDT&E)  CHSENG  representative  when  applicable 

h.  Supportinq  subject  matter  experts  to  present  issues 
and  provide  technical  expertise.  Agencies  should  submit 
attendance  requests  to  CNO  (N842)  for  these  attendees  and  their 
purpose . 

i .  Others  as  appropriate 


1) 

CNO 

(N4 ) 

2) 

CNO 

(Nl) 

3) 

CNO 

(N15) 

4) 

T&E 

WIPT  members  as 

required 


4. 4. 4. 2  Distribution  of  TECG  Results 
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The  results  of  the  TECG  should  be  reported  in  formal 
correspondence  to  all  attendees  with  information  copies 
distributed  to  all  T&E  WIPT  membership. 

4. 4. 4. 3  TECG  for  a  Consolidated  Cryptologic  Program  (CCP) 

The  National  Security  Agency  (NSA)  has  primary 
responsibility  for  developing  and  testing  consolidated 
cryptologic  program  (CCP)  systems.  A  CCP  TECG  should  be  used  to 
identify  Navy-unique  effectiveness  and  suitability  issues  for 
emergency  CCP  Programs,  develop  a  coordinated  Navy  position  on 
cryptologic  T&E  issues,  and  determine  the  extent  of  Navy 
participation  in  multi-service  testing.  A  CCP  TECG  may  also  be 
used  to  resolve  issues  relating  to  assigning  or  canceling  a  CCP 
TEIN . 

4.4.5  T&E  Funding  Responsibility 

4. 4. 5.1  Developing  Activity  Responsibilities 

[ from  SNI  5000. 2E,  4. 4. 5.1:  Except  as  noted  below ,  the  DA 
shall  plan ,  program,  budget,  and  fund  all  resources  identified  in 
the  approved  TEMP,  to  include  the  early  OT  involvement  costs. 
Funds  for  OT&E  should  be  transferred  to  the  OTA  for  distribution 
as  required.  All  T&E  operating  costs  for  OT  squadrons  (VX-1,  VX- 
9,  HMX-1 ,  VMX-22)  will  be  provided  on  a  reimbursable  basis  by  the 
DA  to  COMOPTEVFOR  headquarters.  The  DA  should  not  be  required  to 
fund: 

a.  Fleet  operating  costs  for  RDT&E  support; 

b.  Fleet  travel  for  training; 

c.  Non-program-related  OTA  travel  and  administrative 
costs; 

d.  Non-program-related  Board  of  Inspection  and  Survey 
(INSURV)  travel  and  administrative  costs;  and 

e.  Major  range  and  test  facility  base  (MRTFB) 
institutional  costs.] 

4. 4. 5. 2  Fleet  Commanders  Responsibilities 

[ from  SNI  5000.2E,  4. 4. 5. 2:  Fleet  commanders  should  plan, 
program,  budget,  and  fund  fleet  travel  for  training,  operating 
costs  for  RDT&E  support  provided  by  fleet  units,  and  all  costs 
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associated  with  routine  operational  expenses  except  procurement 
costs  of  the  systems  tested  and  COMOPTEVFOR  costs.} 

4. 4. 5. 3  Board  of  Inspection  and  Survey  (INSURV) 
Responsibilities 

[ from  SNI  5000. 2E,  4. 4. 5. 3:  INSURV  should  plan ,  program , 
budget,  and  fund  INSURV  travel  costs  and  costs  not  related  to 
programs  under  test.] 

4. 4. 5. 4  Non-Acquisition  Programs  Responsibilities 

[from  SNI  5000.2E,  4. 4. 5. 4:  The  R&D  agency  for  a  non-ACAT 
or  pre-ACAT  program  has  responsibilities  equivalent  to  those  of 
the  DA  for  T&E  costs.] 

4.4.6  Research,  Development,  Test  and  Evaluation  (RDT&E) 
Support  Provided  by  Fleet  Commanders 

[ from  SNI  5000. 2E,  4.4.6:  A  developing  agency,  PM, 
COMOPTEVFOR,  INSURV,  or  R&D  agency  shall  request  support  from 
fleet  commanders  for  the  accomplishment  of  T&E  that  is  documented 
in  a  TEMP  or  other  approved  test  document  via  CNO  (CNO  (N84) /Test 
and  Evaluation  Division  (OPNAV  (N842) ) ) .  A  request  should 
normally  be  initiated  9  months  prior  to  test  event.] 

Three  levels  of  RDT&E  support  are  as  follows: 

a.  Dedicated  support  -  precludes  employment  of  the 
supporting  unit(s)  in  other  missions; 

b.  Concurrent  support  -  permits  employment  of  the 
supporting  unit(s)  in  activities  other  than  RDT&E  support,  but 
could  have  an  operational  impact  upon  unit  employment;  and 

c.  Not-to-interf ere  basis  (NIB)  support  -  permits  RDT&E 
operational  employment  of  the  supporting  unit(s)  without 
significant  interference  with  primary  mission  accomplishment. 

4. 4. 6.1  Scheduling  RDT&E  Fleet  Support 

To  ensure  T&E  support  services  are  addressed  in  fleet 
employment  scheduling  conferences,  requests  will  be  submitted  and 
updated  on  a  quarterly  basis  beginning  nine  months  prior  to  the 
quarter  in  which  services  are  needed.  Program  executive  officers 
(PEOs) ,  SYSCOMs,  and  direct  reporting  program  managers  (DRPMs) 
should  request  DT&E  services  and  COMOPTEVFOR  should  request  OT&E 
services  via  formats  in  this  guidebook,  chapter  4,  annex  4-B, 
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using  the  procedures  in  paragraph  4. 4. 6. 1.1  below.  Immediately 
notify  CNO  (N84)/Test  and  Evaluation  Division  (OPNAV  (N842))  of 
any  support  cancellations. 

4. 4. 6. 1.1  Requests 

Requests  may  be  via  message,  correspondence,  or  email  and 
should  provide  the  following  information  as  formatted  in  annex 
4-B. 


a.  Requests  should  be  tailored  to  allow  schedulers  the 
greatest  degree  of  flexibility. 

b.  Include  a  list  of  platforms  (i.e.  ships,  aircraft, 
etc.)  that  have  the  correct  equipment  configuration  installed  to 
support  the  tests. 

c.  Designate  unique  fleet  personnel  support  requirements 
(e.g.:  Sea,  Air,  and  Land  (SEAL)  Teams,  ULQ13  Van/Crew) . 

d.  Service  request  remarks:  State  time  required  to 
install  and  remove  equipment  and  by  whom.  Address  the  following 
questions : 


(1)  Can  it  be  installed  in  an  operational  environment 
(i.e.  pier-side  for  ships,  flight-line  for  aircraft,  etc.)  or 
must  the  unit  be  inducted  into  a  special  facility  (drydock,  ship 
repair  activity  (SRA) ,  depot,  contractor  site,  etc.)? 

(2)  What  is  the  status  of  equipment  certifications 
(e.g.,  electromagnetic  compatibility  (EMC),  DD  Form  1494,  DoD 
Information  Assurance  Certification  and  Accreditation  Process 
(DIACAP) ,  JITC,  Safety)  and  has  the  equipment  installation  been 
approved?  By  whom? 

(3)  Will  installation  affect  unit  operation  or  other 
equipment  onboard? 

(4)  Is  any  crew  training  required?  How  many  riders 
are  required  to  embark  (keep  to  a  minimum) ? 

(5)  If  more  than  one  unit  is  required,  state  which 
units  must  work  together  and  the  minimum  concurrent  time. 

e.  Address  impact  on  program  if  services  are  not  filled 
such  as : 


(1)  Loss  of  programmed  monies  (specify  amount) . 

(2)  Increased  cost  due  to  delay  (specify  amount) . 
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(3)  Impact  on  related  joint  programs  or  operations. 

(4)  Congressional  and/or  OSD  interest  or  direction. 

(5)  Unique  factors: 

(a)  Deployment  schedule  of  test  asset. 

(b)  Overhaul  schedule. 

(c)  "One-of-a-kind"  underway  events  required  for 

testing . 

(6)  Delay  in  projected  production  and  cost  to  Navy. 

f.  Requests  go  to:  CNO  WASHINGTON  DC//N842/ (appropriate 
OPNAV  sponsor  N-code) ,  with  information  copy  to  COMOPTEVFOR 
NORFOLK  VA//01B5/01B6//60P4 . 


4. 4. 6. 1.2  Fleet  Support  Priorities 

CNO  (N84)  assigns  a  fleet  support  priority  relative  to  the 
urgency  of  maintaining  the  RDT&E  schedule,  as  defined  below,  to 
all  RDT&E  support  programs  in  the  quarterly  RDT&E  support 
requirements.  COMOPTEVFOR  collects  support  requirements  and 
coordinates  with  CNO  (N84)  for  assignment  of  priorities. 

a.  Priority  ONE  -  support  takes  precedence  over  normal 
fleet  operations.  RDT&E  support  requiring  the  degree  of  urgency 
to  assign  a  priority  ONE  should  be  requested  in  writing  by  the 
program  sponsor,  without  delegation.  This  request  should  contain 
justifying  information  including: 

(1)  The  next  program  decision  point  and  its  date, 

(2)  The  decision  forum. 


and 


(3)  The  impact  should  the  program  decision  point  slip. 


(4)  The  date  of  the  latest  approved  TEMP. 

b.  Priority  TWO  -  support  takes  precedence  within  normal 
fleet  operations. 

c.  Priority  THREE  -  normal  fleet  operations  take 
precedence  over  support. 

4. 4. 6. 2  Unscheduled  RDT&E  Support  Requirements 
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RDT&E  support  requests  after  the  9-month  deadline 
(paragraph  4. 4. 6.1)  will  be  submitted  to  CNO  (N84)/Test  and 
Evaluation  Division  (OPNAV  (N842))  and  the  program/resource 
sponsor  with  information  copies  to  the  Fleet  Commanders  and 
commands  involved  via  message  that  complies  with  the  format 
provided  in  annex  4-B. 

In  addition  to  the  procedures  described  in  paragraph 
4. 4. 6. 1.1  above,  the  following  steps  should  be  taken. 

a.  Coordinate  justification  with  sponsor  that  the  event 
cannot  be  moved  to  the  next  quarter. 

b.  Coordination  with  all  units  supporting  the  event  in 
the  emergent  timeframe  being  requested. 

c.  Coordinate  request  via  phone  conversation  with  CNO 
N842  Action  Officer. 

d.  Send  a  message  with  the  following  subject  line: 
SUBJ/EMERGENT  (qtr)  QUARTER  FY  (yr)  SUPPORT  REQUEST  FOR  CNO 
PROJECT  (T&E  identification  number)// 

e.  Send  the  message  TO  CNO  WASHINGTON 

DC//N842/ (appropriate  OPNAV  sponsor's  N-code)//  and  INFO  the 
appropriate  scheduling  commands,  units  whose  services  are  needed, 
and  COMOPTEVFOR .  The  Test  and  Evaluation  Division  (OPNAV  (N842)) 
needs  official  OPNAV  sponsor  concurrence  before  authorizing  an 
emergent  request. 

4. 4. 6. 3  RDT&E  Fleet-Support  Scheduling  Agent 

COMOPTEVFOR  is  designated  the  RDT&E  fleet-support 
scheduling  agent  for  CNO  (N84) . 

4. 4. 6. 4  Conduct  of  At-Sea  T&E 

COMOPTEVFOR,  or  designated  representative,  is  responsible 
for  the  conduct  of  at-sea  OT&E.  The  DA  is  responsible  for  the 
conduct  of  at-sea  DT&E. 

4.4.7  Test  and  Evaluation  Master  Plan  (TEMP) 

[from  SNI  5000.2E,  4.4.7:  All  DON  ACAT  programs  shall 
implement  a  TEMP  for  all  developmental,  operational,  and  live- 
fire  test  and  evaluation  in  compliance  with  reference  (a) , 
enclosure  6.  Although  the  TEMP  format  is  discretionary, 
deviations  from  the  standard  DOT&E  policy  require  concurrence 
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from  the  TEMP  approval  authority .  The  TEMP  for  all  ACAT  programs 
shall  include  a  schedule  of  test  phases  and  events  integrated 
with  key  program  objectives  and  decision  points,  and  specify 
entry  criteria  and  resources  required  for  each  phase  of  testing. 
The  TEMP  shall  include  a  summary  of  cost  estimates  by  fiscal  year 
for  the  execution  of  the  TEMP.  For  programs  on  DOT&E  oversight , 
OT  funding  shall  be  clearly  delineated  in  the  summary.  The  TEMP 
shall  identify  anticipated  use  of  M&S  in  system  evaluation  and 
the  M&S  proponent's  W&A  strategy  per  reference  (c)  .  The  TEMP 
documents  the  commitment  between  signatories  to  test  events, 
schedules,  and  resources . 

To  meet  milestones  B  and  C  and  full-rate  production 
decision  reviews  (FRP  DRs) ,  the  PM  for  MDAPs,  MAIS  programs ,  and 
programs  on  the  OSD  T&E  oversight  list  shall  submit  the  TEMP  via 
concurrence  of  primary  DON  stake-holders  (PEO,  OTA,  Sponsor)  to 
the  approval  authorities  designated  in  chapter  1,  table  E1T2,  of 
this  instruction ,  sufficiently  early  to  satisfy  review  timelines 
designated  by  those  agencies .  TEMPS  for  ACAT  II  programs  shall 
be  approved  by  ASN  (RD&A)  .  The  MDA  and  CNO  (N84)  for  Navy 
Programs  or  ACMC  for  non-aviation  Marine  Corps  programs  of  all 
other  ACAT  TEMPs  shall  have  final  approval  authority .  For  CNO 
sponsored  programs ,  CNO  (N84)  is  the  Office  of  the  Chief  of  Naval 
Operations  (OPNAV)  single  point  of  contact  for  TEMP  coordination 
with  OSD.  The  DA  is  responsible  for  distribution  of  an  approved 
TEMP  to  all  agencies  involved  in  testing,  providing  support  or 
resources ,  oversight ,  or  that  have  a  relevant  and  official  need 
to  access  testing  information .] 

See  annex  4-A  of  this  chapter  for  the  signature 
authorities  associated  with  the  appropriate  level  of  an  ACAT 
program . 

Reference  (d)  Exhibit  8A  identifies  distribution 
statements  authorized  for  documents.  Unless  program  information 
is  otherwise  restricted.  Distribution  Statement  D  is  generally 
appropriate  for  TES  and  TEMP. 

4. 4. 7.1  Milestone  B  TEMP  Approval  for  IT  Systems, 
including  NSS,  and  Spectrum  Dependent  Systems 

[from  SNI  5000. 2E,  4. 4.  7.1:  National  security  systems 
(NSS) ,  IT  systems,  and  systems  with  Service  and  joint 
interoperability  requirements,  and/or  systems  that  require  use  of 
the  electromagnetic  spectrum  must  comply  with  DOD  and  Joint 
Chiefs  of  Staff  integrated  architecture  guidance.  The  following 
integrated  architecture  related  items  must  be  specifically 
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addressed  in  milestone  B  TEMP: 

a.  Appropriate  net-ready  (NR)  key  performance  parameter 
(KPP)  products  for  IT,  including  NSS,  programs  per  reference  (e) ; 

b.  Information  assurance  mission  assurance  category  (MAC) 
and  confidentiality  level  per  reference  (f); 

c.  Security  certification  and  accreditation  phase  1 
System  Security  Authorization  Agreement  (SSAA)  or  equivalent  per 
references  (g)  and  (h) ;  and 

d.  Spectrum  certification  documentation:  stage  3  DD-1494, 
Application  for  Equipment  Frequency  Allocation ,  or  note  to 
holders  per  references  (a)  and  (i) .  As  an  alternative ,  the  MDA 
may  grant  authorization  to  proceed  into  engineering  and 
manufacturing  development  (EMD)  phase  if,  per  reference  (i)  , 
justification  and  a  plan  to  achieve  spectrum  supportability  has 
been  provided  to  USD(AT&L)  ,  DoD  Chief  Information  Officer  (CIO), 
DOT&E,  and  the  National  Telecommunications  and  Information 
Administration  (NTIA) . ] 

e.  Include  system  E3  status  and  testing  schedule  to 
ensure  compliance  with  reference  (i)  requirements. 

4. 4. 7. 2  Milestone  C  TEMP  Approval  for  IT  Systems, 
including  NSS,  and  Spectrum  Dependent  Systems 

[from  SNI  5000. 2E,  4. 4.  7. 2:  As  systems  mature  during  the 
development  process ,  more  detailed  information  becomes  available . 
The  following  integrated  architecture  related  items  must  be 
specifically  addressed  in  milestone  C  and  beyond  test  phases: 

a.  Information  assurance  MAC,  and  confidentiality  level, 
and  related  IA  controls  per  reference  (f) ; 

b.  Security  certification  and  accreditation  phase  2  SSAA 
or  equivalent  per  references  (g)  and  (h)  ; 

c.  Security  certification  and  accreditation  interim 
authority  to  test  (IATT)  and  interim  authority  to  operate  (IATO) 
per  references  (g)  and  (h)  ; 

d.  Appropriate  NR  KPP  for  IT,  including  NSS,  programs  per 
reference  (e) ; 

e.  JITC  assessment  of  interoperability  readiness  for  an 
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OT  phase  or  the  Interoperability  Certification  and  Evaluation 
Plan  (ICEP)  is  in  place  per  reference  (e) ; 

f.  E3  Verification  and  validation  (V&V)  reports  and 
documentation  per  reference  (i) ;  and 

g.  Spectrum  certification  development:  stage  4  DD-1494 , 
Application  for  Equipment  Frequency  Allocation ,  or  note  to 
holders  per  references  (a)  and  (i) .  As  an  alternative ,  either 
USD (AT&L)  may  grant  authorization  to  proceed  into  production  and 
deployment  phase  or  DoD  CIO  may  grant  a  waiver  if,  per  reference 
(i) ,  justification  and  a  plan  to  achieve  spectrum  supportability 
has  been  provided  to  USD (AT&L),  DoD  CIO,  DOT&E,  and  the  NTIA .] 

4. 4. 7. 3  Capabilities,  Key  System  Attributes  (KSAs) ,  and 
Key  Performance  Parameters  (KPPs)  Traceability  to  Critical 
Operational  Issues  (COIs) 

[ from  SNI  5000.2E ,  4. 4.  7. 3:  For  DON  programs ,  traceability 
will  be  consistent  among  the  analysis  of  alternatives ,  ICD,  CDD, 
and  CPDs ,  acquisition  program  baseline  (APB) ,  and  the  TEMP.  The 
TEMP  shall  document  how  specific  capabilities ,  KSAs,  and  KPPs 
trace  to  COIs  and  how  each  will  be  addressed  in  T&E.  Post 
milestone  B  test  results  will  be  tracked  to  monitor  progress 
toward  achieving  KSA,  KPP ,  and  COI  performance  measures 
identified  in  the  TEMP. 

As  described  in  chapter  1,  section  1.1. 2. 3  of  this 
instruction ,  KSAs  are  system  or  sub-system  capabilities  with 
priority  to  Navy  leadership  for  cost,  schedule  or  performance 
insight,  but  do  not  meet  criteria  as  KPPs.  KPPs  are  those 
capabilities  that  leadership  considers  of  such  significance  that 
if  not  demonstrated  are  reason  for  program  reassessment  or 
possible  termination .] 

4. 4. 7. 4  Performance  Thresholds  and  Critical  Technical 
Parameters  (CTPs) 

[ from  SNI  5000. 2E,  4. 4.  7. 4:  Testable  and  measurable 
performance  thresholds  for  DT,  LFT&E,  and  OT  shall  be 
established,  tracked,  and  reported  throughout  the  acquisition 
life-cycle .  The  CTPs  are  engineering  measures  derived  from  the 
capabilities  documents  and  are  established  as  appropriate  to  aid 
the  DA  during  system  development.  Those  CTPs  that  best  relate 
system  design  maturity  to  achieve  KPPs  and  KSAs  shall  be 
incorporated  in  the  TES  and  TEMP  by  the  PM.  The  operational 
parameters  and  critical  issues  derived  from  the  ICD,  CDD,  and  CPD 
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to  be  used  for  OT  shall  be  established  and  incorporated  in  the 
TEMP  by  COMOPTEVFOR  and  Director ,  MCOTEA.  The  numerical  values 
for  DT  and  OT  shall  be  the  same  as  the  performance  parameters 
established  in  the  CDD  and  CPD.  See  reference  (a) ,  enclosure  6, 
for  implementation  requirements  for  all  DON  ACAT  programs.] 

CTPs  should  provide  early  technical  indicators  of  a 
program's  operational  effectiveness. 

4. 4. 7. 5  Test  Planning  for  Commercial  and  Non-Developmental 

Items 

[from  SNI  5000. 2E,  4.4.  7.5:  Use  of  commercial  products 
built  to  non-DoD  specifications  dictates  the  need  for  the  PM  and 
the  T&E  community  to  be  cognizant  of  the  commercial  T&E  data, 
standards ,  and  methods  used  to  provide  assurance  for  these 
products.  In  some  cases,  commercial  T&E  data  or  use  of 
commercial  T&E  practices  by  the  DoD  T&E  community  may  provide 
adequate,  reliable ,  and  verifiable  information  to  meet  specific 
DT&E,  OT&E,  or  LFT&E  goals.  When  it  can  be  shown  that 
commercially  available  T&E  data  or  use  of  commercial  T&E 
practices  meet  specific  DoD  T&E  needs  and  costs  less  than  their 
DoD  T&E  counterpart ,  they  should  be  considered  by  the  PM  or  the 
OTA,  and  may  be  used  to  support  T&E  requirements .  The  PM  shall 
ensure  T&E  planning  includes  an  assessment  and  evaluation  (as 
appropriate)  of  performance  in  the  intended  operational 
environment . ] 

T&E  of  commercial  and  non-developmental  items  is  required 
to  ensure  that  the  item  will  perform  its  intended  military 
application.  The  PM  or  OTA,  in  the  development  of  a  TEMP,  will 
assess  the  benefits  and  risks  associated  with  T&E  of  commercial 
and  non-developmental  items  and  what  verifiable  information  meets 
specific  DT&E,  OT&E,  or  LFT&E  goals  (to  assume  effective 
performance  in  the  intended  operational  environment) . 

4. 4. 7. 6  Use  of  Existing  T&E  Infrastructure 

[ from  SNI  5000. 2E,  4. 4. 7.  6:  Planners  shall  use  existing 
investment  in  DoD  infrastructure  (ranges,  facilities ,  and  land) 
and  other  DoD  resources ,  to  include  embedded  instrumentation  for 
conduct  of  T&E  unless  it  is  demonstrated  that  the  required 
capability  does  not  exist  within  DoD  or  it  is  more  cost  effective 
to  use  a  non-DoD  resource .  Projected  T&E  investment  needs  will 
be  annotated  in  the  TEMP.  Infrastructure  shortfalls  that 
adversely  impact  the  conduct  of  a  specific  T&E  requirement  will 
be  identified  in  limitations  to  test  in  the  TEMP.  To  affect 
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useful  T&E  data  from  embedded  instrumentation ,  T&E  expertise  must 
be  engaged  in  the  capabilities  development  process  and  early 
design  considerations .] 

4. 4. 7. 7  Environment,  Safety,  and  Occupational  Health 
(ESOH)  Considerations 


[ from  SNI  5000. 2E,  4. 4.  7.  7:  The  T&E  Strategy  and  TEMP  must 
address  the  PM' s  analysis  of  ESOH  risks  and  mitigation  measures , 
to  include  safety  releases  per  reference  (j) ,  for  the  system  or 
item.  The  intent  is  to  ensure  testers  understand  the  ESOH 
hazards,  the  control  measures  adopted  by  the  PM,  and  the  risks 
accepted  by  the  appropriate  authority  per  reference  (a) . 

Prior  to  any  live  fire,  developmental  or  operational  test 
decision  that  may  affect  the  physical  environment ,  the  PM,  per 
references  (k)  and  (1) ,  shall  ensure  that  all  applicable  National 
Environmental  Policy  Act  (NEPA)  and  Executive  Order  (EO)  12114 
requirements  are  satisfied.  Testing  shall  be  planned  to  ensure 
sufficient  time  to  comply  with  applicable  environmental 
requirements  including  NEPA  and  EO  12114.  Environmental  impact 
considerations  that  directly  affect  testing  shall  be  addressed  in 
the  TEMP  and  respective  test  plans  as  limitations  or  conditions 
of  the  testing.  Additionally,  the  PM' s  designated  environmental 
manager  in  coordination  with  SYSCOM  and  fleet  environmental 
staffs  supporting  ranges  and  fleet  end-user's,  shall  verify  the 
review  of  potential  environmental  planning  requirements  for  the 
system's  T&E  and  will  ensure  that  these  requirements  will  be 
fully  satisfied.  The  requirements  will  be  considered  fully 
satisfied  only  if  the  system's  testing  and  usage  is  within  the 
scope  of  existing  environmental  documentation  and  permits ,  or  the 
test  range,  training  range,  and  end  users  have  verified  they  have 
the  necessary  information ,  time,  and  resources  to  meet  the 
requirements  before  testing,  training,  or  IOC  occurs  at  their 
location .  Test  activities  that  may  require  NEPA  and  EO  12114 
analyses  shall  be  identified  in  the  NEPA  and  EO  12114  compliance 
schedule ,  which  is  required  as  part  of  the  Program's  programmatic 
environment,  safety  and  occupational  health  evaluation  (PESHE) 
and  acquisition  strategy .  See  reference  (a) ,  enclosure  8, 
paragraph  2f,  and  reference  (m)  for  implementation  requirements 
for  all  DON  ACAT  programs.] 

See  reference  (n)  for  guidance  in  minimizing  the  impact  on 
the  environment.  Reguirements  for  environmentally  compliant 
facilities,  tools,  and  methods  should  be  identified  early  by  the 
DA  and  OTA  to  allow  for  funding  and  development.  The  results  of 
these  reguirements  should  be  outlined  in  the  PESHE.  Those 
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aspects,  which  directly  affect  testing,  should  be  addressed  in 
the  TEMP  as  limitations  or  conditions  of  the  testing. 

4. 4. 7. 7.1  Environment,  Safety,  and  Occupational  Health 

(ESOH) 


Systems  acquisition  policy  requires  ESOH  regulatory 
compliance  and  risk  management  throughout  the  acquisition 
process.  To  provide  essential  information  to  decision  makers, 
the  T&E  strategy  and  TEMP  should  assess  the  PM' s  acceptance  of 
residual  ESOH  risks  and  control  measures,  to  include  safety 
releases,  for  the  system  or  item.  The  intent  is  to  ensure  that, 
prior  to  OT&E  and  fielding,  the  testers  and  users  understand  the 
ESOH  hazards,  the  control  measures  adopted  by  the  PM,  and  the 
residual  risks  accepted  by  the  PM.  Early  participation  of  ESOH 
expertise  on  the  T&E  WIPT  is  recommended  to  assure  appropriate 
issues  are  addressed  during  test  planning  and  execution. 
Additionally,  T&E  planning  should  consider  testing  for  specific 
system  characteristics  that  may  have  an  environmental  or 
personnel  safety  and  health  impact  (e.g.  air  emissions,  noise, 
liquids/effluent  characterization) . 

4. 4. 7. 7. 2  Responsibilities  for  Environmental 
Compliance  During  Testing 

The  PM  is  responsible  for  compliance  with  National 
Environmental  Policy  Act  (NEPA)  and  E.O  12114  requirements, 
particularly  as  they  affect  test  ranges  and  operational  areas. 

The  testing  strategy  and  TEMP  should  include  NEPA  and  E.O. 12114 
documentation  requirements,  and  describe  how  analyses  will  be 
conducted  to  support  test  site  selection  decisions. 

COMOPTEVFOR  or  Director,  MCOTEA,  or  designees,  are  action 
proponents  for  dedicated  OT&E.  See  chapter  6  of  this  guidebook, 
paragraph  6.3.2,  National  Environmental  Policy  Act  and  E.O.  12114 
Environmental  Effects  Abroad,  for  action  proponents'' 
responsibilities . 

4. 4. 7. 7. 3  Safety  Releases  for  Testing 

Reference  (a)  requires  the  PM  to  provide  safety  releases 
to  developmental  and  operational  testers  prior  to  any  test  using 
personnel.  A  safety  release  communicates,  to  the  activity  or 
personnel  performing  the  test,  the  risks  associated  with  the  test 
and  the  mitigating  factors  required  to  safely  complete  the  test. 

A  secondary  function  of  the  process  is  to  ensure  that  due 
diligence  is  practiced  with  respect  to  safety  in  the  preparation 
of  the  test  by  the  sponsor.  A  safety  release  is  normally  provided 
by  the  PM  after  appropriate  hazard  analysis.  Safe  test  planning 
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includes  analysis  of  the  safety  release  related  to  test 
procedures,  equipment,  and  training. 

4. 4. 7. 8  Modeling  and  Simulation  (M&S) 

[from  SNI  5000. 2E,  4. 4.  7. 8:  Per  reference  (a),  enclosure 
6,  M&S  may  be  used  during  T&E  of  an  ACAT  program  to  represent 
conceptual  systems  that  do  not  exist  and  existing  systems  that 
cannot  be  subjected  to  actual  environments  because  of  safety 
requirements  or  the  limitations  of  resources.  M&S  applications 
include  hardware,  software ,  operator- in- the- loop  simulators ,  land 
based  test  facilities ,  threat  system  simulators ,  C4I  systems 
integration  environments ,  facilities ,  and  other  simulations  as 
needed.  M&S  shall  not  replace  the  need  for  OT&E  and  will  not  be 
the  primary  evaluation  methodology .  M&S  shall  not  be  the  only 
method  of  meeting  independent  OT&E  for  beyond  LRIP  decisions  per 
section  2399  of  title  10,  U.S.C.  M&S  is  a  valid  T&E  tool  that 
per  reference  (c)  requires  W&A  to  supplement  or  augment  live 
test  data.  The  PM  is  responsible  for  V&V  of  M&S  and  the 
accreditation  of  M&S  used  for  DT&E.  The  OTA  is  responsible  for 
accreditation  of  M&S  used  for  OT&E.  The  PM  is  required  to 
complete  V&V  prior  to  an  accreditation  decision  by  the  OTA.  M&S 
previously  accredited  for  other  programs  or  test  phases  requires 
accreditation  for  specific  use  by  the  OTA  for  each  OT&E.  Use  of 
M&S  shall  be  identified  in  the  TEMP  for  each  DT&E  and  OT&E  phase 
it  is  intended  to  support.  M&S  required  resources  shall  be 
listed  in  the  TEMP. 

The  PM  shall  identify  and  fund  required  M&S  resources 
early  in  the  acquisition  life  cycle.  The  T&E  WIPT  shall  develop 
and  document  a  robust,  comprehensive ,  and  detailed  evaluation 
strategy  for  the  TEMP,  using  both  simulation  and  test  resources , 
as  appropriate.  Planning  shall  allow  for  pre-test  prediction  and 
post-test  reconciliation  of  M&S  data.  See  reference  (a), 
enclosure  6,  for  implementation  requirements  for  all  DON  ACAT 
programs . ] 

Examples  of  M&S  that  may  be  used  for  DT&E  and  OT&E 
include : 


a.  to  assess  the  adequacy  of  future  test  plans; 

b.  to  assess  performance  against  threats  that  there  is 
not  a  real  system  to  test  against; 

c.  to  adequately  test  complex  systems  in  dense  combat 
environments ; 
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d.  to  conduct  pre-test  predictions  of  system  performance; 

and 

e.  to  augment  live  test  data  in  assessing  KPPs,  CTPs,  and 

MOPs  . 

4. 4. 7. 8.1.  Live,  Virtual  and  Constructive  M&S 
Environments 


a.  Live  simulations  in  general  are  with  real  personnel, 
using  real  systems  in  staged  scenarios,  operating  in  realistic 
activities  against  surrogate  targets  and  threats,  usually 
conducted  in  exercises  on  ranges. 

b.  Virtual  simulation  are  generally  conducted  with  real 
personnel,  interacting  with  simulated  system  capabilities  and  in 
simulated  environments. 

c.  Constructive  simulations  are  generally  conducted  with 
both  simulated  human  and  system  capabilities  within  a  scenario 
stimulated  by  human  inputs. 

4. 4. 7. 9  Interoperability  Testing  and  Certification 

[from  SNI  5000.2E ,  4. 4.  7. 9:  The  OTA  has  a  responsibility 
to  evaluate  progress  towards  joint  interoperability  as  part  of 
each  testing  phase.  Interoperability  testing  consists  of  intra- 
Service  Navy-Marine  Corps,  joint  Service,  and  where  applicable , 
allied  and  coalition  testing.  Interoperability  requirements , 
including  requirement  for  incremental  fielding  of  services  and 
applications ,  are  covered  in  detail  by  references  (e) ,  (o) ,  and 

(P) •  Systems  designated  for  FORCEnet  compliance  must  achieve 
joint  interoperability  test  certification.  Testing  for  FORCEnet 
compliance  will  be  in  conjunction  with  DT  and  OT  to  the  maximum 
extent  possible .  Lab  environments  used  to  conduct  live, 
constructive ,  and  virtual  interface  and  interoperability  testing 
must  be  verified,  validated,  and  accredited  by  the  PM  and  OTA  per 
reference  (c) .  See  reference  (a)  for  implementation  requirements 
for  DON  ACAT  programs.  Some  IT  systems  and  NSS  that  meet  the 
eligibility  criteria  outlined  in  reference  (e) ,  enclosures  C  and 
E,  may  request  waivers  or  test  exemptions.  The  following  general 
procedures  apply  to  IT  systems,  including  NSS: 

a.  Interoperability  capabilities  (requirements)  will  be 
documented  in  the  CDD  and  CPD.  The  PM  is  responsible  for 
developing  information  support  plan  (ISP)  for  IT,  including  NSS, 
programs  based  upon  documented  requirements. 
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b.  Marine  Corps-unique  interfaces  shall  be  tested  during 
DT&E  by  MARCORSYSCOM  or  PEO-LS ,  typically  at  Marine  Corp  Tactical 
Systems  Support  Activity  (MCTSSA) . 

c.  Navy-unique  interfaces  shall  be  tested  during  DT&E  by 
DAs  (e.g.,  PEO-C4I  and  PEO-Enterprise  Information  Systems  (EIS) ) . 

d.  DON  PMs  will  coordinate  with  JITC  to  develop  and 
execute  interoperability  testing  for  certification  of  IT, 
including  NSS,  programs  per  reference  (e) .  When  appropriate ,  for 
complex  IT  systems,  including  NSS,  the  PM  shall  obtain  an 
interoperability  certification  evaluation  plan  (ICEP)  from  JITC. 

e.  Navy  systems  processing  data  links  (e.g.,  Link 
4/11/16/22)  and  character  oriented  message  for  human  readable 
text  (e.g.,  United  States  message  text  format  (USMTF)  and  optical 
transport  hierarchy  (OTH) -Gold) ,  must  be  tested  for  joint 
interoperability  by  Naval  Center  for  Tactical  Systems 
Interoperability  (NCTSI) ,  and  by  JITC  for  joint  certification. 

f.  Marine  Corps  systems  processing  data  links  (e.g.,  link 
4/11/16/22)  and  character  oriented  message  human  readable  text 
(e.g.,  USMTF  and  OTH-Gold)  must  be  initially  tested  for  joint 
interoperability  by  MCTSSA,  then  by  JITC  for  joint  certification . 

g.  Standard  conformance  testing  with  interoperability 
certification  of  specific  data  link  interfaces  should  be 
accomplished  prior  to  IOT&E.  Per  reference  (e) ,  a  Joint 
interoperability  test  certification  or  an  interim  certification 
to  operate  (ICTO)  shall  be  accomplished  prior  to  FRP  DR. 

h.  Per  references  (a),  (e) ,  and  (o)  and  SECNAVINST 

5000. 2E,  table  E2T2,  all  IT,  including  NSS,  ACAT  programs  are 
required  to  receive  Joint  Staff  (J-6)  interoperability  and 
supportability  certifications  by  FRP  DR.  This  certification 
shall  be  used  as  the  basis  for  certification  of  compliance  with 
the  applicable  FORCEnet  technical  standards.] 

4. 4. 7. 9.1  Joint  Interoperability  Process  and  Support 

Although  JITC  is  the  sole  joint  interoperability  certifier 
in  DoD  per  reference  (e) ,  certification  test  execution  can  be 
conducted  by  JITC  or  program  manager  (PM) .  The  PM  can  either 
fund  and  task  JITC  for  a  separate  certification  test  on  all 
phases  of  test  execution  (e.g.,  test  plan,  test  configuration  and 
data  collection  and  analysis)  or  leverage  DT,  exercises,  and  OT 
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events  as  long  as  the  test  plan  has  JITC  concurrence. 

4. 4. 7. 9. 1.1  Three  Types  of  Joint  Interoperability 
Test  Command  (JITC)  Certification  Reports 

a.  Standards  conformance  certification:  A  system  is 
certified  for  conformance  to  a  standard  (e.g.,  UHF  DAMA  SATCOM, 

HF  Radio  MIL-STD,  NATO  STANAGs,  etc) .  This  certification  is 
necessary,  but  not  sufficient  in  itself  for  fielding. 

b.  Full  certification:  Full  system  certification.  System 
meets  "all"  certified  NR-KPPs  and  is  ready  for  fielding. 

c.  Partial  certification:  Partial  system  certification. 
System  meets  subset  of  the  certified  NR-KPPs  and  that 
part/version  of  the  system  is  ready  for  fielding. 

4.4.7.10  Information  Assurance  (IA)  and  Information 
Systems  Security  Certification  and  Accreditation 

[ from  SNI  5000.2E,  4.4.7.10:  IA  is  critical  to  net- 
centric  warfare.  The  MAC  and  Confidentiality  Level,  as  approved 
by  the  Deputy  CIO  for  the  Navy  or  Marine  Corps,  establish  IA 
control  measures  that  must  be  incorporated  into  a  system. 

Control  measures  are  implemented,  verified  and  validated  via 
security  certification  and  accreditation  (SCA) .  Reference  (f) 
also  requires  V&V  of  control  measures  through  vulnerability 
assessments  and  penetration  testing.  The  DoD  Information 
Assurance  Certification  and  Accreditation  Process  (DIACAP) 
requires  the  independent  V&V  of  IA  control  measures  through 
vulnerability  assessments  and  penetration  testing.  The  PM 
coordinates  with  the  OTA,  and  the  designated  approving  authority 
(DAA)  (CNO/CMC ,  or  designee)  to  determine  the  IA  DT&E  and  OT&E 
test  requirements  in  order  to  optimize  test  activity .  The  PM 
documents  SCA  and  IA  controls  in  the  TEMP.  An  authorization  to 
operate  must  be  obtained  prior  to  OT  from  the  DAA.  For  early  OT 
events,  such  as  operational  assessments ,  this  can  be  an  interim 
authority  to  test  (IATT)  ,  interim  authority  to  operate  (IATO)  ,  or 
authority  to  operate  (ATO)  .  To  begin  IOT&E,  an  IATO  or  ATO  must 
be  obtained.  The  OTA  will  evaluate  IA  controls  and  ability  to 
protect,  detect,  respond,  and  restore  systems  during  OT  based 
upon  MAC  and  confidentiality  level.  The  OTA  does  not  certify  the 
system  for  security  or  IA,  but  evaluates  the  effectiveness , 
suitability ,  and  survivability  of  the  system  in  its  intended 
environment .  ] 

4.4.7.11  Anti-Tamper  Verification  and  Validation  Testing 
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[ from  SNI  5000. 2E,  4.4.7.11:  Anti-Tamper  (AT)  V&V  is  a 
requirement  for  all  systems  implementing  an  AT  plan  to  ensure  the 
AT  techniques  stated  in  the  AT  plan  are  fully  implemented  and 
respond  appropriately  in  the  event  of  tampering .  This  V&V  must 
be  accomplished  by  an  independent  team  and  be  funded  by  the 
parent  acquisition  program.  See  reference  (a)  for  implementation 
requirements  for  DON  ACAT  programs  that  contain  critical  program 
information  and  AT  countermeasures  DON'S  AT  technical  authority 
(NAVAIRSYSCOM) ,  will  assist  acquisition  programs  in  understanding 
AT  V&V  requirements ,  program  test  plan  development ,  and 
interactions  with  the  DoD  V&V  community . ] 

NAVAIRSYSCOM,  in  concert  with  DoD  AT  Executive  Agent 
(Assistant  Secretary  of  the  Air  Force  for  Acquisition) ,  will 
assist  the  PM  in  designating  the  independent  team  to  perform 
anti-tamper  V&V  testing. 

Per  reference  (a) ,  the  purpose  of  the  EMD  phase  includes 
ensuring  the  protection  of  information  with  techniques  such  as 
anti-tamper  (AT) . 

The  FRP  decision  should  not  be  given  favorable 
consideration  until  AT  implementation  is  fully  verified  and 
validated  during  DT  and  OT,  and  ready  for  production. 

Reference  to  the  AT  annex  in  the  PPP  may  be  adequate  for 
TEMP  documentation  if  test  resource  requirements  can  be  properly 
identified  in  Part  IV  of  the  TEMP.  When  necessary  an 
appropriately  classified  AT  annex  to  the  TEMP  may  be  required. 

The  intent  of  AT  testing  is  to  integrate  testing  within 
the  events  of  routine  DT  and  OT  rather  than  requiring  increased 
testing  events.  The  conduct  of  V&V  for  anti-tamper  (AT) 
requirements  is  best  served  with  a  multi-disciplined  team  of 
subject-matter  experts.  This  system  engineering  process  must 
consider  protection  of  the  system' s  mission  and  performance 
requirements.  Programs  are  responsible  for  satisfactory  V&V  of 
their  respective  AT  plan  implementation  prior  to  milestone  C, 
foreign  military  sale,  or  direct  commercial  sale  decisions.  DON 
AT  Technical  Agent  (PMR-51)  can  assist  acquisition  programs  in 
understanding  AT  V&V  requirements,  program  V&V  test  plan 
development,  and  interactions  with  the  DoD  V&V  community. 

4.4.7.12  Test  and  Evaluation  Identification  Number  (TEIN) 
Assignment 

[ from  SNI  5000. 2E,  4.4.7.12:  A  TEIN  is  required  before 
requesting  fleet  support  services.  The  TEIN  assists  in  tracking 
T&E  documentation ,  scheduling  fleet  services ,  and  execution  of 
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oversight  requirements.  The  PM  shall  request ,  in  writing ,  a  TEIN 
from  CNO  (N84)  via  the  resource  sponsor.  Navy  programs  will 
utilize  the  TEIN  to  identify  TEMP  documents . ] 

The  recommended  format  for  a  TEIN  request  is  provided  in 
this  guidebook,  chapter  4,  annex  4-C.  CNO  (N84)  identifies  six 
types  of  programs  via  a  code  letter  preceding  the  number  in  a 
TEIN  as  follows: 

a.  DON  ACAT  programs  (no  code  letter) 

b.  Tactics  programs  (Code  "T") 

c.  Software  qualification  programs  (Code  "S") 

d.  OSD-Directed  joint  T&E  programs  (Code  "J") 

e.  Non-acquisition  programs  (Code  "K") 

f.  Foreign  comparative  testing  (FCT)  programs  (Code  "F"), 
only  when  fleet  services  will  be  required  to  support  testing. 

4.4.7.12.1  Pre-requisite  Documentation 

TEINs  should  not  be  assigned  to  programs  that  do  not  have 
approved  documentation.  Minimum  documentation  requirements  are: 

a.  An  approved  ICD  for  ACAT  programs, 

b.  A  RDT&E  budget  item  justification  sheet  (R-2  Exhibit) 
for  non-acquisition  programs, 

c.  Documentation  as  discussed  in  SECNAVINST  5000. 2E, 
chapter  1,  paragraph  1.4.6,  for  Abbreviated  Acquisition  Programs, 
or 

d.  Designation  as  a  software  qualification  program. 

By  endorsement,  the  program  sponsor  should  ensure  the 
request  for  TEIN  assignment  is  supported  by  valid  documentation. 

4.4.7.12.2  Program  Groups 

TEINs  should  be  structured  for  generic  project  groups  and 
subprojects.  Generic  project  groups  should  be  consolidated  by 
identifying  the  basic  project  and  functionally  related 
sub-projects.  If  the  project  for  which  a  TEIN  is  being  requested 
is  a  sub-project  of  an  existing  project  group,  it  should  be  so 
noted  and  the  generic  project  number  should  be  included. 
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Likewise,  multiple  TEINs  may  be  requested  in  a  single  letter. 

4.4.7.12.3  Consolidated  Cryptologic  Programs  (CCP) 

Assignment  of  CCP  TEINs  should  be  per  the  following 
procedures : 

a.  Commander  Naval  Security  Group  (COMNAVSECGRU)  should 
review  draft  project  baseline  summary  one  (PBS-I)  on  new  CCP 
programs . 

b.  If  COMNAVSECGRU  determines  that  the  system  has 
significant  and  continuous  Navy  tactical  implications,  the  PBS-I 
will  be  sent  to  COMOPTEVFOR  for  review. 

c.  If  COMOPTEVFOR  concurs,  COMNAVSECGRU  should  include 
the  requirement  for  Navy  operational  testing  in  PBS-I  comments  to 
the  National  Security  Agency  and  forward  a  recommendation  for 
TEIN  assignment  to  Test  and  Evaluation  Division  (OPNAV  (N842)) . 

4.4.7.12.4  Inactive  TEINs 

Test  and  Evaluation  Division  (OPNAV  (N842))  should,  with 
DA  and  program  sponsor  review,  cancel  TEINs,  which  have  been 
inactive  in  excess  of  1  year  and/or  require  no  further  testing. 

4.4.7.13  TEMP  Approval 

A  major  function  of  the  T&E  WIPT  is  to  resolve  issues. 

Once  issues  are  resolved  to  the  satisfaction  of  an  0-6  review  for 
all  ACAT  I,  II,  and  programs  with  OSD  T&E  oversight,  the  PM 
should  submit  the  smooth  TEMP  to  the  DA  (SYSCOM,  PEO,  DRPM)  for 
concurrence  and  further  routing.  The  DA  should  distribute  copies 
of  the  smooth  TEMP  to  all  signature  offices  and  coordinate  the 
sequential  routing  of  a  smooth  signature  page  to  the  OTA  and 
program  sponsor  (user  representative)  for  their  concurrence.  For 
Navy  sponsored  TEMPs  with  all  concurrent  signatures  the  DA  should 
coordinate  delivery  of  the  TEMP  signature  page  to  CNO  (N84)  for 
Service  component  approval  prior  to  forwarding  to  ASN (RD&A)  for 
component  acquisition  executive  (CAE)  approval.  Marine  Corps 
sponsors  are  authorized  to  forward  Marine  Corps  TEMPs  direct  to 
ASN (RD&A) .  Use  the  cover  page  in  this  guidebook,  chapter  4, 
annex  4-A,  for  ACAT  I  programs  and  all  DON  programs  with  OSD  T&E 
oversight.  TEMP  signature  routing  for  ACAT  II,  III,  and  IV 
programs  should  comply  with  the  sample  TEMP  cover  pages  provided 
in  this  guidebook,  chapter  4,  annex  4-A.  A  separate  Navy  TEMP 
cover  sheet  format  is  provided  for  legacy  software  qualification 
testing . 
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4.4.7.13.1  TEMP  Timing 

A  TEMP  is  to  be  submitted  to  OSD  not  later  than  45  days 
prior  to  the  milestone  decision  point  or  subsequent  program 
initiation  if  a  PM  must  have  an  OSD-approved  document  by  the 
decision  date.  For  programs  newly  added  to  the  OSD  T&E-oversight 
list,  the  TEMP  must  be  submitted  within  120  days  of  such  written 
designation . 

4.4.7.13.2  TEMP  Draf ting/ Submitting 

The  PM/DA  drafts  the  TEMP  with  T&E  WIPT  participation. 

The  PM/DA  should  draft  the  LFT&E  section  of  the  TEMP.  The  OTA  is 
responsible  for  drafting  the  operational  test  and  evaluation 
inputs  to  include  resource  requirements  and  estimated  costs  for 
execution  of  OT&E.  ACAT  IVT  draft  TEMPs  should  be  sent  to  the 
applicable  program  sponsor  for  review  and  to  the  OTA  for  review 
and  endorsement  prior  to  going  to  CNO  (N84)  and  MDA  for  approval. 

Requirements  developed  in  the  analysis  of  alternatives  and 
incorporated  in  the  increment  under  development  in  the  CDD/CPD 
should  be  listed  in  the  TEMP.  Other  increment  requirements 
should  be  time-phased  or  put  in  TEMP  annexes,  as  appropriate. 

When  the  T&E  WIPT  membership  considers  the  draft  TEMP 
ready  for  approval,  the  PM  and  DA  Lead  should  distribute  copies 
of  the  draft  TEMP  to  all  members  of  the  T&E  WIPT,  staff  action 
offices  for  all  TEMP  signatories,  and  DASN (RDT&E)  CHSENG  for  0-6 
level  review  and  comment.  All  comments  should  be  returned  to  the 
PM/DA  T&E  Lead  for  consolidation,  consideration,  and 
incorporation.  The  PM  and  DA  should  convene  a  T&E  WIPT  session 
to  review  the  consolidated  TEMP  comments,  with  rationale  and 
disposition  of  all  recommended  changes,  and  the  final  TEMP.  All 
known  issues  should  be  resolved  before  submitting  the  TEMP  for 
final  approval.  The  PM  and  DA  is  responsible  for  sending  copies 
of  the  TEMP  and  disposition  of  all  0-6  level  comments  to  all 
signature  offices.  If  the  program  is  subject  to  OSD  T&E 
oversight,  the  DA  should  deliver  appropriate  copies  to  OSD  per 
reference  (a) .  For  Navy  sponsored  programs,  CNO  (N84)  is  the 
single  OPNAV  point  of  contact  with  OSD  for  TEMP  coordination. 

4.4.7.14  TEMP  Distribution 

The  DA  distributes  approved  TEMPs  to  all  appropriate 
offices  and  commands.  Approved  TEMPs  for  ACAT  IVM  programs 
should  be  sent  to  the  applicable  program  sponsor  and  COMOPTEVFOR 
or  Director,  MCOTEA  for  information. 

4.4.7.15  TEMP  Updates 
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Within  DON,  TEMP  updates  (as  described  in  DoD  Instruction 
5000.02)  fall  into  two  categories,  revision  and  administrative 
change.  A  revision  is  signed  by  all  TEMP  signatories  and  is 
identified  with  a  sequential  alphabetic  designation  to  the  TEIN. 
An  administrative  change  may  be  promulgated  by  the  program 
manager  based  on  the  concurrence  of  the  T&E  WIPT  members  who 
represent  the  signatories.  An  administrative  change  is 
identified  with  a  sequential  numeric  designation  to  the  TEIN. 

4.4.7.15.1  TEMP  Revision 

A  revision  should  be  planned  for  each  major  program 
milestone  (i.e.  MS-C,  FRP  DR,  and  significant  FOT&E  periods),  but 
may  not  be  required  depending  on  currency  of  TEMP  information.  A 
revision  is  required  for  changes  to  evaluation  criteria,  to  scope 
of  testing,  to  major  resource  changes,  and/or  to  performance 
requirements,  whenever  those  occur.  A  revision  may  also  be 
required  if  unanimous  agreement  is  not  reached  to  submit  an 
update  as  an  administrative  change.  All  revisions  follow  the 
approval  chain  for  signature  of  principals  at  every  level  as 
detailed  in  the  DON  Acquisition  and  Capabilities  Guidebook,  annex 
4-A.  The  TEMP  title  includes  "Revision"  and  a  sequential 
alphabetic  designation. 

4.4.7.16  Administrative  Change  to  TEMP 

An  administrative  change  reflects  fact-of-life  changes 
such  as  personnel,  schedule,  test  status,  history,  etc.  These 
changes  are  assessed  as  low  risk  for  adversely  impacting  the 
scope  of  planned  testing,  milestones,  or  the  Acquisition  Program 
Baseline . 


TEMP 


4.4.7.16.1  Determination  on  Administrative  Change  to  a 


Proposed  administrative  changes  will  be  reviewed  by  the 
T&E  WIPT.  If  each  T&E  WIPT  member  representing  a  signatory  of 
the  TEMP  concurs,  the  program  manager  documents  concurrence  from 
each  with  the  promulgation  of  the  administrative  change  to  the 
TEMP.  If  there  is  not  complete  agreement  of  those  T&E  WIPT 
members,  the  program  manager  may  solicit  more  senior  agreement 
from  those  dissenting  organizations.  In  no  case  should  there  be 
untimely  delay  in  beginning  a  revision  cycle  in  order  to  solicit 
those  more  senior  agreements.  Navy  programs  soliciting  Office  of 
Secretary  of  Defense  (OSD)  for  more  senior  agreements  are 
represented  by  CNO  (N84) .  USMC  programs  need  Director,  MCOTEA' s 
concurrence  before  soliciting  OSD  for  more  senior  agreements. 

Navy  programs  not  on  OSD  Test  and  Evaluation  (T&E)  Oversight  may 
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request  that  CNO  (N84)  facilitate  discussions  or  convene  a  test 
and  evaluation  coordination  group  (TECG)  in  accordance  with 
SECNAVINST  5000.2  series  to  resolve  dissenting  opinions 
concerning  appropriate  application  of  an  administrative  change 
for  a  TEMP  update.  No  program  should  unduly  delay  (in  no 
instance  should  a  delay  be  over  30  days)  beginning  a  revision 
cycle  to  obtain  adjudication  on  the  proposed  administrative 
change.  If  the  proposed  changes  are  considered  significant  by  a 
representative  of  a  TEMP  signatory,  then  the  TEMP  update  would 
become  a  revision  and  handled  accordingly. 

4.4.7.16.2  Procedure  for  an  Administrative  Change  to  a 

TEMP 


The  program  manager  promulgates  a  TEMP  change  with  a  cover 
letter  referencing  the  concurrences  of  the  applicable  T&E  WIPT 
members  and  a  short  summary  of  the  administrative  changes  to  the 
TEMP.  A  TEMP  change  package  is  distributed  to  all  TEMP  holders. 
At  a  minimum,  the  TEMP  change  package  includes: 

a.  The  cover  letter. 

b.  A  record  of  change  pages. 

c.  Change  bars  in  the  right  margin  for  all  changes. 

d.  A  notation  indicating  the  TEIN  number,  version,  and 
change  number  (e.g.,  TEMP  XXXX  Rev  A  CH-1)  at  the  upper  right 
corner  on  all  pages  containing  changes.  Changes  are  numbered 
consecutively  by  original  or  revision. 

Programs  on  OSD  T&E  oversight  may  require  an  approval 
letter  from  the  oversight  agencies  authorizing  the  administrative 
change  to  the  TEMP.  A  copy  of  the  approval  letter  becomes  part 
of  the  program  manager' s  change  package  that  is  distributed  to 
all  TEMP  holders. 

4 . 5  Developmental  Test  and  Evaluation  (DT&E) 

[ from  SNI  5000.2E,  4.5:  The  DA  shall  conduct  adequate  DT&E 
throughout  the  development  cycle  to  support  risk  management , 
provide  data  on  the  progress  of  system  development  and  attainment 
of  performance  criteria  specified  in  TEMP,  and  to  determine 
readiness  for  OT.  For  DON  programs ,  DT&E  shall  be  conducted  by 
the  DA  through  contractor  testing  or  government  test  and 
engineering  activities.  DT&E  will  be  sufficiently  robust  to 
adequately  characterize  system  performance  in  an  operational 
environment  and  provide  clear  expectations  of  performance  at 
IOT&E.  Developmental  testing  schedules  require  sufficient  time 


4-43 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


to  evaluate  results  before  proceeding  to  independent  OT  phases. 
See  reference  (a) ,  enclosure  6 ,  for  implementation  requirements 
for  all  DON  ACAT  programs .] 

4.5.1  DT&E  Data 

[from  SNI  5000. 2E,  4.5.1:  Data  and  findings  from  DT&E  may 
be  used  by  the  OTA  to  supplement  OT  data  in  system  operational 
evaluation .  Within  proprietary,  contractual,  and  regulatory 
considerations  all  DT  data  shall  be  available  to  appropriate 
oversight  agencies .  Data  will  normally  be  made  available  upon 
completion  of  analysis  by  the  primary  analyzing  agency.  DT 
results  (data  and  reports,  as  applicable)  shall  be  provided  to 
the  OTA  on  a  regular  basis  to  provide  for  periodic  updates  to 
subsequent  DT  and  OT  planning  and  execution .  In  preparation  for 
IOT&E  or  dedicated  OT  phase  supporting  a  milestone ,  a  DT  report 
shall  be  provided  to  the  OTA  a  minimum  of  30  days  prior  to  the 
start  of  OT  in  order  to  ensure  the  OTA's  test  plans  can  be 
finalized.  See  reference  (a) ,  enclosure  6,  for  implementation 
requirements  for  all  DON  ACAT  programs.] 

During  combined  DT/OT  and  integrated  testing,  DT  data  and 
reports  will  be  handled  as  specified  by  mutual  agreement  between 
the  lead  test  agency  and  the  system  program  manager. 

4.5.2  Information  Assurance  and  Security  Certification  during 
Developmental  Test  (DT) 

[ from  SNI  5000.2E,  4.5.2:  IA  testing  and  system  SCA  shall 
be  conducted  by  the  PM  as  part  of  the  development  process  to 
ensure  that  appropriate  control  measures  are  in  place  to  support 
the  assigned  MAC  and  confidentiality  level.  The  MAC  and 
confidentiality  level  should  be  identified  in  capabilities 
development  documents  and  have  approval  of  the  Deputy  CIO  for  the 
Navy  and  Marine  Corps,  as  appropriate.  Security  certification 
and  accreditation  testing  shall  be  accomplished  during  DT  by  the 
PM  in  conjunction  with  the  SCA  agent  as  approved  by  the  DAA  to 
ensure  the  appropriate  combination  of  security  controls  and 
procedures  have  been  implemented  to  achieve  the  required  level  of 
protection,  per  references  (g)  and  (h) ,  the  DAA  shall  provide  an 
accreditation  statement  prior  to  the  FRP  DR,  full-rate  production 
and  deployment  approval.  The  PM  shall  coordinate  with  the  OTA, 
the  security  certification  authority,  and  the  DAA  to  optimize 
efficiency  of  testing  requirements.] 

4.5.3  Production  Qualification  Test  and  Evaluation 
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[ from  SNI  5000. 2E,  4.5.3:  See  reference  (a),  enclosure  6, 
for  Implementation  requirements  for  all  DON  ACAT  programs.] 

4.5.4  DT&E  Phases  and  Procedures 

DT&E  should  be  conducted  in  three  major  phases  to  support 
pre-systems  acquisition,  systems  acquisition,  and  sustainment 
phases  of  the  acquisition  model.  The  specific  objectives  of  each 
phase  should  be  developed  by  the  DA  and  outlined  in  the  TEMP. 
Modeling  and  simulation  techniques,  if  used  to  assess  areas  in 
which  testing  is  not  yet  possible  or  practical,  as  well  as 
establishing  and  implementing  software  development  metrics, 
requires  proper  validation  (see  OTRR  certification  criteria  in 
SECNAVINST  5000. 2E,  paragraph  4.6.1).  annex  4-D  depicts  a 
notional  schedule  of  DT  phases  within  the  phases  of  the 
acquisition  model.  This  guidebook  continues  to  define 
developmental  and  operational  test  phases  to  support  legacy 
program  management  as  well  as  to  continue  supporting  the 
requirement  to  complete  independent  evaluation  of  test  objectives 
by  different  test  activities  that  collaboratively  effect  test 
events  in  an  integrated  test  construct. 

4. 5. 4.1  DT-A 

DT-A  is  conducted  as  required  during  technology 
development  to  support  milestone  B.  The  Technology  Development 
Strategy  requires  test  plans  supporting  evaluation  criteria  for 
selection  between  competitive  prototypes,  assessing  technology 
maturity  to  support  Technology  Readiness  Level  reviews,  and 
quantifying  reliability  levels  as  well  as  contributing  to  early 
reliability  growth  development  and  assessing  capability  to 
perform  in  the  anticipated  operational  environment  in  which  a 
system  will  be  used.  During  TD  phase,  testers  should  be 
communicating  measurement  criteria  to  help  identify  affordable 
thresholds  and  objectives  for  KPPs  and  KSAs  in  the  Capabilities 
Development  Document. 

4. 5. 4. 2  DT-B/DT-C  (TECHEVAL) 

DT-B  is  conducted  during  engineering  and  manufacturing 
development  (EMD)  phase  to  support  the  milestone  C  decision.  DT- 
C  is  conducted  after  milestone  C  during  low-rate  initial 
production  to  support  the  full-rate  production  decision  review. 
The  last  portion  of  DT-C  prior  to  IOT&E  may  be  designated 
TECHEVAL.  This  period  is  for  rigorous  technical  testing  at  the 
end  of  development  to  demonstrate  system  stability,  technical 
maturity,  and  to  determine  if  the  system  is  ready  for  IOT&E.  DT- 
C/TECHEVAL  should  include,  as  a  minimum,  testing  and  assessment 
to  determine: 
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a.  System  performance  and  verification  of  CTP  compliance 
(including  electronic  countermeasures  (ECM) ,  electronic  counter 
countermeasures  (ECCM) ) , 

b.  System  and  personnel  safety,  occupational  health 
hazards,  the  effects  of  volatile  materials,  effects  of  aging  and 
environmental  stress  on  energetic  materials,  and  compliance  with 
insensitive  munitions  criteria, 

c.  All  electromagnetic  environmental  effects,  such  as: 
electromagnetic  compatibility  (EMC) ,  electromagnetic  interference 
(EMI),  electromagnetic  vulnerability  (EMV) ,  hazards  of 
electromagnetic  radiation  to  ordnance  (HERO)  and  fuel  (HERF) , 
hazards  of  electromagnetic  radiation  (RADHAZ)  to  personnel 
(HERP) ,  lightning,  electrostatic  discharge  (ESD) ,  and 
electromagnetic  pulse  (EMP) , 

d.  The  effectiveness  and  supportability  of  any  built-in 
diagnostics,  and 

e.  Compliance  with  FORCEnet  and  joint  technical  standards 
in  the  global  information  grid  technical  guidance  (GTG)  which  now 
includes  the  DoD  information  technology  standards  registry  (DISR) 
that  replaced  the  joint  technical  architecture  (JTA) . 

The  OTA  and  the  DA  should  determine  what  constitutes 
production  representative  hardware  and  what  degree  of  software 
maturity  (e.g.,  software  requirements,  software  quality,  computer 
resource  utilization,  build  release  content)  is  necessary  for 
technical  evaluation  (TECHEVAL)  data  to  be  used  in  support  of 
OT&E.  Software  to  be  used  for  IOT&E  should  be  the  same  as  or 
functionally  representative  of  that  software  intended  for  fleet 
use  at  initial  operational  capability  (IOC)  of  a  system  and  will 
be  validated  during  DT . 

4. 5. 4. 3  DT-D 

DT-D  is  conducted  during  full-rate  production  and 
deployment  and  operations  and  support.  Production  acceptance 
test  and  evaluation  (PAT&E)  should  be  the  responsibility  of  the 
DA.  PAT&E  objectives,  excluding  factory  inspections  and 
certifications,  should  be  outlined  in  the  TEMP. 

4. 5. 4. 4  DT&E  Schedules 

The  DA  should  provide  OTA  with  schedules  of  DT&E 
activities,  program  and  system  documentation  (in  draft  form,  if 
necessary),  and  access  to  DT&E  activities. 
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4. 5. 4. 5  Operator  and  Maintenance  Training 

Prior  to  IOT&E,  the  DA  is  responsible  for  providing  fleet 
and  field  representative  system  operator  and  maintenance  training 
for  the  operational  test  director  (OTD)  and  members  of  the 
operational  test  team  (including  crew  members,  staffs,  and 
interoperable  units,  when  applicable) .  Scheduling  of  this 
training  requires  early  coordination  between  OTA,  the  DA,  and 
fleet  and  field  units. 

4. 5. 4. 6  Live  Fire  Test  and  Evaluation  (LFT&E) * 

The  DA  is  responsible  for  LFT&E  per  statute  section  2366 
of  title  10,  U.S.C.  and  submission  of  the  LFT&E  section  in  part 
IV  of  the  TEMP.  Paragraph  4.9  in  chapter  4  of  this  guidebook 
provides  mandatory  procedures  and  guidance  on  LFT&E. 

*Not  applicable  to  AIS  programs 

4. 5. 4. 7  United  States  Marine  Corps  (USMC)  Developmental 
Test  and  Evaluation 


The  USMC  DT&E  handbook  provides  detailed  guidance  for 

DT&E . 

4. 5. 4. 7.1  DT&E  of  Amphibious  Vehicles 

All  DT&E  of  amphibious  vehicles  and  amphibious  tests  of 
other  equipment  or  systems  used  by  a  landing  force  in  open 
seaways  should  be  conducted  by,  or  be  under  the  direct 
supervision  of.  Commander,  MARCORSYSCOM  with  appropriate 
NAVSEASYSCOM  or  PEO  and  DRPM  coordination.  The  Director,  MCOTEA 
coordinates  OT  planning,  scheduling,  and  evaluation  of  such 
systems  with  OPTEVFOR. 

4 . 6  Certification  of  Readiness  for  Operational  Testing 
4.6.1  DON  Criteria  for  Certification 

[ from  SNI  5000. 2E,  4.6.1:  Per  reference  (a),  the  following 
list  of  criteria  for  certification  of  readiness  apply  to  all 
IOT&E  for  all  DON  programs.  For  all  OT  other  than  IOT&E ,  the  PM 
with  the  support  of  the  T&E  WIPT  and  concurrence  of  the  OTA  may 
tailor  criteria  listed  below  in  subparagraphs  4.6.1b  through 
4. 6. It.  The  MDA  may  add  criteria  as  necessary  to  determine 
readiness  for  OT. 

a.  The  TEMP  is  current  and  approved.  Testing  prior  to 
milestone  B  must  have  an  approved  TES  as  discussed  in  this 
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chapter ,  paragraph  4.3.1. 

b.  T&E  results  indicate  DT  objectives  and  performance 
thresholds  identified  in  the  TEMP  have  been  satisfied  or  are 
projected  to  meet  system  maturity  for  the  CDD  and  CPD,  as 
appropri ate . 

c.  All  significant  areas  of  risk  have  been  identified  and 
corrected  or  mitigation  plans  are  in  place. 

d.  Test  results  have  been  provided  to  the  OTA  not  less 
than  30  days  prior  to  the  commencement  of  OT ,  unless  otherwise 
agreed  to  by  the  OTA. 

e.  Entrance  Criteria  for  OT  identified  in  the  TEMP  have 
been  satisfied. 

f.  System  operating,  maintenance ,  and  training  documents 
have  been  provided  to  the  OTA  no  less  than  30  days  prior  to  the 
OTRR,  unless  otherwise  agreed  to  by  the  OTA. 

g.  Logistic  support,  including  spares,  repair  parts,  and 
support  and  ground  support  equipment  is  available  as  documented. 

Discuss  any  logistics  support  which  will  be  used  during  OT&E  but 
will  not  be  used  with  the  system  when  fielded  (e.g.,  contractor 
provided  depot  level  maintenance) . 

h.  The  OT&E  manning  of  the  system  is  adequate  in  numbers, 
rates,  ratings,  and  experience  level  to  simulate  normal  operating 
conditions . 

i.  Training  has  been  completed  and  representative  of  that 
planned  for  fleet  units. 

j.  All  ranges,  facilities ,  and  resources  required  to 
execute  OT  including  instrumentation,  simulators ,  targets, 
expendables ,  and  funding  have  been  identified  and  are  available . 

k.  Models,  simulators ,  and  targets  have  been  accredited 
for  intended  use.] 

See  OPNAVINST  3960. 15A,  Validation  of  Navy  Threat 
Simulators,  Targets,  and  Digital  Threat  Models  and  Simulations, 
dated  29  Oct  2007,  for  requirements  and  procedures  to  accredit. 

[1.  The  system  provided  for  OT&E,  including  software ,  is 


4-48 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


production  representative.  Differences  between  the  system 
provided  for  test  and  production  representative  configuration 
must  be  addressed  at  the  OTRR. 

m.  Threat  information  (e.g.,  threat  system  characteristics 
and  performance ,  electronic  countermeasures ,  force  levels, 
scenarios ,  and  tactics) ,  to  include  security  classification , 
required  for  OT&E  is  available  to  satisfy  OTA  test  planning . 

n.  The  system  is  safe  to  use  as  planned  in  the  concept  of 

employment  and  the  PM  has  provided  the  appropriate  safety 
release  (s)  for  the  phase  of  test  to  be  conducted.  Any 
restrictions  to  safe  employment  are  stated.  The  ESOH  program 
requirements  have  been  satisfied  per  references  (j)  ,  (k)  ,  (1)  , 

(m)  ,  (n)  ,  (q)  ,  (r)  ,  and  (s)  .  The  system  complies  with  Navy  and 

Marine  Corps  ESOH  and  hazardous  waste  requirements,  where 
applicable .  ESOH  and  hazardous  waste  reviews  and  reports  have 
been  provided  to  COMOPTEVFOR  or  Director ,  MCOTEA.  When  an 
energetic  is  employed  in  the  system,  WSESRB  criteria  for  conduct 
of  test  have  been  met.] 

The  PM  is  responsible  for  providing  a  safety  release 
for  any  test  that  involves  personnel. 

[o.  All  software  is  sufficiently  mature  and  stable  for 
fleet  introduction.  All  software  trouble  reports  are  documented 
with  appropriate  impact  analyses.  There  are  no  outstanding 
trouble  reports  that: 

(1)  Prevent  the  accomplishment  of  an  essential 

capability; 


(2)  Jeopardize  safety,  security,  or  other  requirements 
designated  "critical"; 

(3)  Adversely  affect  the  accomplishment  of  an 
essential  capability  and  no  work-around  solution  is  known;  or 

(4)  Adversely  affect  technical,  cost,  or  schedule 
risks  to  the  project  or  to  life-cycle  support  of  the  system,  and 
no  work-around  solution  is  known. 

p.  For  software  qualification  testing  (SQT) ,  a  statement 
of  functionality  that  describes  the  software  capability  has  been 
provided  to  COMOPTEVFOR  and  CNO  (N84) .  For  programs  to  be  tested 
by  MCOTEA,  the  SQT  statement  of  functionality  has  been  provided 
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to  Director ,  MCOTEA. 

q.  For  aviation  programs ,  there  are  no  uncorrected 
NAVAIRSYSCOM  deficiencies  that  affect: 

(1)  Airworthiness ; 

(2)  Capability  to  accomplish  the  primary  or  secondary 

mission ; 

(3)  Safety  of  the  crew/operator/maintainer; 

(4)  Integrity  of  an  essential  subsystem;  and 

(5)  Effectiveness  of  the  operator  or  an  essential 

subsystem. 

r.  For  a  program  with  interoperability  requirements  (e.g., 
information  exchange  requirements  in  ICD/CDD/CPDs) ,  appropriate 
authority  has  approved  the  ISP  and  JITC  concurs  that  program 
interoperability  has  progressed  sufficiently  for  the  phase  of  OT 
to  be  conducted. 

s.  For  spectrum  management  per  reference  (i) ,  a  stage  3 
"Developmental"  DD-1494  (at  a  minimum)  is  required  for  testing. 

t.  For  IT  systems,  including  NSS,  the  system  has  been 
assigned  a  MAC  and  confidentiality  level.  System  certification 
accreditation  documents ,  including  the  phase  2  SSAA  and  the  IATT, 
or  IATO,  or  platform  IT  designation  letter,  as  applicable ,  have 
been  provided  to  the  OTA.] 

4.6.2  DON  Procedures  for  Certification 

[ from  SNI  5000.2E,  4.6.2:  The  SYSCOM  commander,  PEO,  DRPM, 
and  PM  shall  convene  an  OTRR  prior  to  certifying  readiness  for 
IOT&E  per  reference  (a) .  The  need  to  conduct  and  the  procedures 
for  an  OTRR  for  all  OT  other  than  IOT&E  shall  be  determined  by 
the  SYSCOM  commander,  PEO,  DPRM,  and  PM  with  the  concurrence  of 
the  OTA  and  based  on  recommendations  from  the  T&E  WIPT.  An  OTRR 
shall  consist  of  those  members  of  the  testing  team  who  provide 
input  to  the  certification  criteria ,  and  representatives  from  CNO 
(N84)  and  DC,  CD&I,  the  program  sponsor  (Navy  only),  DASN (RDT&E) , 
and  COMOPTEVFOR  and  Director ,  MCOTEA.  For  programs  on  OSD  T&E 
Oversight ,  representatives  from  Office  of  the  Under  Secretary  of 
Defense  for  Acquisition,  Technology  and  Logistics  (OUSD (AT&L) ) 
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and  DOT&E  shall  be  included. 

The  SYSCOM  commander ,  PEO,  and  DRPM  shall  evaluate  and 
make  a  determination  that  a  system  is  ready  for  OT&E  (normally  30 
days  prior  to  OT&E) .  The  SYSCOM  commander,  PEO,  and  DRPM  shall, 
unless  otherwise  directed  by  ASN (RD&A)  for  programs  on  the  OSD 
T&E  oversight  list  make  one  of  the  following  certifications .] 

OTRRs  may  be  administrative  as  defined  in  the  TEMP; 
separate  paper  process,  i.e.  a  checklist  of  agreed  entrance 
criteria  that  is  confirmed  complete  and  ready;  or  more  formal 
briefing  sessions  with  key  stakeholders  in  attendance.  For 
independent  operational  test  periods  or  test  events  requiring 
dedicated  high  value  or  limited  resources  and/or  fleet  assets, 
and  for  IOT&E  and  follow-on  operational  test  and  evaluation 
(FOT&E) ,  the  more  formal  briefing  session  is  recommended. 

4. 6. 2.1  Certification  for  OT  Without  T&E  Exceptions 

[from  SNI  5000.2E,  4.  6. 2.1:  Certify  to  COMOPTEVFOR  or 
Director,  MCOTEA  by  message  that  a  system  is  ready  for 

OT _ (specific  operational  test  phase)  ,  as  required  by  the 

TEMP,  without  deferrals  or  waivers.  Provide  information  copies 
to  CNO  (N84)  and  DC,  CD&I ,  the  program  sponsor  (Navy  only) , 

ASN  (RD&A),  fleet  commands,  INSURV  for  ships,  NAVAIRSYSCOM 
Technical  Assurance  Board  (NTAB)  for  aircraft ,  other  interested 
commands,  and  when  a  program  is  on  the  OSD  T&E  oversight  list,  to 
DOT&E.  See  this  chapter,  paragraph  4.6.4  for  explanation  of 
exceptions . ] 

4. 6. 2. 2  Certification  for  OT  With  T&E  Exceptions 

[ from  SNI  5000.2E,  4.  6. 2. 2:  Certify  to  CNO  (N84)  or  DC, 

CD&I  by  message  that  a  system  is  ready  for  OT _ (specific 

operational  test  phase) ,  as  required  by  the  TEMP,  with  waiver 
and/or  deferral  requests.  Provide  information  copies  to  the 
program  sponsor  (Navy  only,  who  must  provide  formal  concurrence 
with  proposed  exceptions) ,  ASN  (RD&A) ,  COMOPTEVFOR  and  Director, 
MCOTEA,  and  when  a  program  is  on  the  OSD  T&E  oversight  list,  to 
DOT&E.  ] 


4. 6. 2. 2.1  T&E  Exceptions 

[from  SNI  5000.2E,  4. 6. 2. 2.1:  There  are  two  types  of  T&E 
exceptions  to  the  certification  for  OT :  waivers  and  deferrals .] 

4 . 6 . 2 . 2 . 1 . 1  Waivers 
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[ from  SNI  5000. 2E,  4.  6. 2. 2. 1.1:  The  term  "waivers"  applies 
to  a  deviation  from  the  criteria  identified  for  certification  in 
paragraph  4.6.1  of  this  chapter.  Waivers  do  not  change  or  delay 
any  testing  or  evaluation  of  a  system. ] 

Waivers  are  meant  to  allow  a  system  to  enter  OT&E  even 
though  all  the  selected  criteria  in  paragraph  4.6.1  -  DON 
criteria  for  certification,  certification  of  readiness  for 
operational  testing,  have  not  been  met.  Waivers  generally  do  not 
change  or  delay  any  system  or  testing  reguirements ,  nor  affect 
the  scope  of  the  OT .  Waivers  apply  only  to  the  data  or  system 
maturity  identified  for  entrance  into  the  OT  period. 

Waivers  are  not  normally  requested  for  EOA  or  OA  periods. 
Unless  otherwise  directed  by  the  MDA,  waiver  requests  are 
appropriate  for  only  OT  periods  that  support  FRP  or  fielding 
decisions.  Before  requesting  any  waiver,  the  PM  should  be 
confident  that  the  program  is  on  track  and  the  system  will 
achieve  overall  effectiveness,  suitability,  and  survivability 
during  IOT&E. 

Data  for  any  waived  criteria  may  be  used  in  COMOPTEVFOR' s 
final  analysis  to  resolve  COIs,  determine  system  operational 
effectiveness,  operational  suitability,  and  any  recommendation 
regarding  fleet  introduction. 

4. 6. 2. 2. 1.2  Deferrals 

[ from  SNI  5000. 2E,  4.  6. 2. 2. 1.2:  The  term  "deferrals" 
applies  to  a  delay  in  testing  requirements  directed  by  the  TEMP. 

A  deferral  moves  a  testing  requirement  from  one  test  period  to  a 
later  period.  Deferred  items  cannot  be  used  in  the  analysis  to 
resolve  COIs;  however,  the  OTA  may  comment  on  operational 
considerations  in  the  appropriate  sections  of  the  test  report.  A 
deferral  does  not  change  the  requirement  to  test  a  system 
capability ,  function ,  or  mission ,  only  the  timeframe  in  which  it 
is  evaluated.  ] 

Deferrals  are  meant  to  appropriately  delay  planned  testing 
from  one  test  period  to  a  later  test  period  that  can  be 
predicted,  funded,  scheduled  and  agreed  on  by  key  stakeholders 
below.  Deferrals  do  not  change  the  quantitative  or  qualitative 
value  of  a  requirement,  only  the  timeframe  that  it  will  be 
tested . 


4 . 6 . 2 . 2 . 1 . 2 . 1  When  Deferrals  are  Appropriate 
[ from  SNI  5000. 2E,  4. 6. 2. 2. 1.2.1:  Deferrals  will  not 
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normally  be  granted  for  EOAs ,  operational  assessments  (OAs) ,  or 
any  OT&E  prior  to  IOT&E.  Performance  shortfalls  should  be 
identified  sufficiently  early  to  document  system  capability 
maturity  in  the  appropriate  CDD,  CPD,  and  TEMP.  When 
unanticipated  problems  with  system  maturity  or  test  resources 
would  unduly  delay  an  OT  period ,  deferrals  provide  for  continued 
testing  and  efficient  use  of  scheduled  resources  (e.g.r  ranges, 
operational  units,  and  assets) . ] 

Deferrals  for  OT&E  periods  may  be  granted  only  after  the 
program  and  resource  sponsors  have  justified  that  the  system  is 
necessary,  useful,  and  adds  capability  to  the  fleet  despite 
deviating  from  testing  of  a  particular  TEMP  requirement.  (See 
paragraph  4. 6.4.3  below)  COMOPTEVFOR  will  then  make  a 
determination  on  adequacy  of  the  test  and  a  recommendation  to 
conduct  or  delay  testing  because  of  deferral  requests.  Deferrals 
should  not  be  requested  for  EOA  or  OA  periods.  Early  assessments 
of  all  capabilities  help  identify  risks,  unforeseen  problems,  or 
provide  information  useful  to  system  design. 

4 . 6 . 2 . 2 . 1 . 2 . 2  Limitations  to  Test 

[ from  SNI  5000. 2E,  4. 6. 2. 2. 1.2. 2:  A  deferral  may  result  in 
limitations  to  the  scope  of  testing  that  may  preclude  COMOPTEVFOR 
and  Director,  MCOTEA  from  fully  resolving  all  COIs .] 

4 . 6 . 2 . 2 . 1 . 2 . 3  Resolution  of  COIs 

Deferred  items  cannot  be  used  in  the  analysis  to  resolve 
COIs;  however,  the  OTA  may  comment  on  operational  considerations 
in  the  appropriate  sections  of  the  test  report. 

Because  a  function,  sub-system,  or  mission  capability  is 
not  ready  for  operational  testing,  a  deferral  allows  relief  from 
the  TEMP  requirement  to  test  and  evaluate  data  that  would 
knowingly  be  collected  against  an  immature  capability;  yet 
provide  an  opportunity  to  evaluate  the  overall  system 
capabilities  that  have  been  identified  as  adding  needed  and 
useful  capability  to  the  fleet.  The  deferral  documents  the  need 
for  future  investment  to  achieve  the  desired  capability  for  the 
decision  authority,  while  allowing  the  OTA  to  focus  reporting  on 
the  known  capability  to  date.  However,  the  OTA  should  provide 
comments  on  the  operational  perspective  of  employing  the  system 
without  the  deferred  capability/item . 

4.6.3  CNO  (N84)  and  DC,  CD&I  Approval  of  a  Deferral  Request 

[ from  SNI  5000. 2E,  4.6.3:  Deferrals  for  OT&E  periods  may 
only  be  granted  after  the  program  and  resource  sponsor  and  DC, 


4-53 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


CD&I  have  justified  that  the  system  is  necessary  and  useful ,  and 
adds  capability  to  the  operating  forces  despite  deviating  from 
testing  of  a  particular  TEMP  requirement.  COMOPTEVFOR  and 
Director ,  MCOTEA  will  then  make  a  determination  on  adequacy  of 
the  test  and  a  recommendation  to  conduct  or  delay  testing  because 
of  deferral  requests .  The  necessary  programmatic  inputs  or 
changes  to  account  for  required  additional  test  periods  in  which 
the  deferred  items  are  to  be  tested  must  be  provided  to  CNO  (N84) 
via  concurrence  of  resource  sponsor  (Navy  only)  or  direct  to  DC, 
CD&I  for  Marine  Corps  programs.  CNO  (N84)  and  DC,  CD&I  will  make 
final  determination  and  authorize  OTA  to  proceed  to  test.  For 
programs  on  the  OSD  T&E  oversight  list,  the  deferral (s)  must  be 
coordinated  with  DOT&E  prior  to  CNO  (N84)  and  DC,  CD&I  approval. 

Approval  of  deferral  requests  do  not  alter  the  associated 
requirement,  and  approved  deferrals  shall  be  tested  in  subsequent 
operational  testing. ] 

4.6.4  Waiver  and  Deferral  Requests 

[ from  SNI  5000. 2E,  4.6.4:  Waivers  and  deferrals  shall  be 
requested  in  the  OT&E  certification  message.  If  a  waiver  or 
deferral  request  is  anticipated,  the  PM  shall  coordinate  with  the 
program  sponsor  (Navy  only) ,  CNO  (N84)  and/or  DC,  CD&I,  and 
COMOPTEVFOR  and  Director ,  MCOTEA  prior  to  the  OTRR  or  similar 
review  forum.  Deferrals  shall  be  identified  as  early  as 
possible ,  normally  no  later  than  30  days  prior  to  OTRR.  Use  of 
the  T&E  WIPT  or  similar  forum  is  also  recommended  to  ensure  full 
understanding  of  the  impact  on  operational  testing. 

When  requesting  a  waiver  or  deferral ,  the  PM  shall  outline 
the  limitations  the  deferral  or  waiver  will  place  upon  the  system 
under  test  and  their  potential  impacts  on  fleet  use.  Further,  a 
statement  shall  be  made  in  the  OT&E  certification  message  noting 
when  approved  deferrals  will  be  available  for  subsequent  OT. ] 

See  recommended  certification  message  format  found  in 
annex  4-E  of  chapter  4  in  this  guidebook  for  submitting  requests. 

4.7  OT&E 

4.7.1  Independent  OT&E 

[ from  SNI  5000. 2E,  4.7.1:  Reference  (a)  requires  an 
independent  organization  be  responsible  for  all  OT&E.  OT&E  shall 
be  conducted  by  the  OTA  or  an  agent  designated  by  the  OTA  for 
ACAT  I,  IA,  II,  III,  and  IVT  programs.  COMOPTEVFOR  and  the 
Director ,  MCOTEA,  are  responsible  for  planning  and  conducting 
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OT&E,  reporting  results ,  providing  evaluations  of  each  tested 
system's  operational  effectiveness  and  suitability ,  and 
identifying  and  reporting  system  deficiencies.  Additionally, 
COMOPTEVFOR  is  responsible  for  providing  inputs  to  tactics,  as 
appropriate ,  and  making  recommendations  regarding  fleet 
introduction.  OTA  shall  determine  whether  thresholds  in  the  CDD 
and  CPD  have  been  satisfied  as  part  of  the  overall  evaluation  of 
the  system's  performance.  See  reference  (a),  enclosure  6,  for 
implementation  requirements  for  all  DON  ACAT  programs  requiring 
OT&E.  ] 


A. 1.1.1  Start  of  OT&E 

[ from  SNI  5000.2E,  4.  7.1.1:  COMOPTEVFOR  and  Director, 
MCOTEA  may  commence  operational  testing  upon  receipt  of  a 
certification  message  unless  waivers  or  deferrals  are  requested. 

When  waivers  or  deferrals  are  requested,  COMOPTEVFOR  and 
Director ,  MCOTEA  may  start  testing  upon  receipt  of  waiver  or 
deferral  approval  from  CNO  (N84)  and  DC,  CD&I.  The  OTA  shall 
issue  a  start  test  message  when  OT  begins.] 

4. 7. 1.2  De-certification  and  Re-certification  for  OT&E 

[ from  SNI  5000. 2E,  4. 7. 1.2:  When  evaluation  of  issued 
deficiency  and  anomaly  reports  or  other  information  indicates  the 
system  will  not  successfully  complete  OT&E,  de-certification  may 
be  originated  by  the  SYSCOM  commander ,  PEO,  and  DRPM,  after 
coordination  with  the  program  sponsor  and  PM,  to  withdraw  the 
system  certification  and  stop  the  operational  test.  Withdrawal 
of  certification  shall  be  accomplished  by  message  to  CNO  (N84) 
and  DC,  CD&I  and  COMOPTEVFOR  and  Director ,  MCOTEA  stating,  if 
known,  when  the  system  will  be  evaluated  for  subsequent 
certification  and  restart  of  testing.  When  a  system  undergoing 
OT&E  has  been  de-certified  for  OT,  the  SYSCOM  commander ,  PEO,  and 
DRPM  must  re-certify  readiness  for  OT&E  prior  to  restart  of  OT 
per  paragraph  4 . 6.2. ] 

4. 7. 1.3  Operational  Test  and  Evaluation  (OT&E)  for  Non- 
Acquisition  Programs 

OTA  services  may  be  required  to  evaluate  capabilities  of 
non-acquisition  programs  or  pre-systems  acquisition  equipment  or 
programs.  At  a  minimum,  the  requesting  agency  must  provide  a 
statement  describing  mission  functions  with  thresholds  for  any 
capabilities  of  interest.  A  test  plan  must  be  approved  by  the 
OTA  prior  to  any  OT . 
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4.7.2  OT&E  Plans 

[ from  SNI  5000. 2E,  4.7.2:  See  reference  (a),  enclosure  6, 
for  implementation  requirements  for  DON  ACAT  programs  requiring 
OT&E.  ACAT  I,  II,  and  programs  on  the  OSD  oversight  list  require 
DOT&E  approval.  An  ACAT  I  program  or  an  OSD  designated  T&E 
oversight  program  requires  an  OA  to  support  an  LRIP  decision . 

For  programs  on  the  OSD  T&E  oversight  list,  the  OA  test  plans 
require  formal  approval  by  DOT&E.  An  OA  does  not  have  to  use 
production  representative  articles .] 

4. 7. 2.1  OT&E  Phases  and  Procedures 

OT&E  can  consist  of  operational  assessments  (OAs) , 
verification  of  corrected  deficiencies  (VCD) ,  software 
qualification  test  (SQT) ,  the  independent  phase  of  OT  during 
"combined  DT/OT,"  IOT&E,  and  FOT&E.  All  forms  of  OT&E  require 
compliance  with  reference  (a),  covered  by  SECNAVINST  5000. 2E, 
chapter  4,  paragraph  4.6.  With  evolutionary  acquisition,  a 
program  may  have  multiple  IOT&Es  as  new  increments  of 
requirements  are  added  to  the  development.  For  each  program,  or 
program  increment  under  development,  COIs  should  be  developed  by 
the  OTA  and  documented  in  the  TEMP.  The  COIs  are  linked  to  CNO 
or  CMC  capability  needs  established  in  the  CDD  and  CPD  and  are 
evaluated  while  conducting  scenarios  that  are  representative  of 
the  system' s  operational  environment  and  workload  of  typical 
users.  The  phases  listed  below  should  be  tailored  through 
further  sub-division,  as  required.  Annex  4-D  depicts  a  notional 
schedule  of  OT  phases  within  the  phases  of  the  acquisition  model. 

This  guidebook  continues  to  define  developmental  and 
operational  test  phases  to  support  legacy  program  management  as 
well  as  to  continue  supporting  the  requirement  to  complete 
independent  evaluation  of  test  objectives  by  different  test 
activities  that  collaboratively  effect  test  events  in  an 
integrated  test  construct. 

4. 7. 2. 1.1  Operational  Assessments  (OAs) 

Operational  Assessments  are  conducted  by  an  independent 
OTA.  The  focus  of  an  OA  is  to  assess  trends  noted  in  development 
efforts,  programmatic  voids,  risk  areas,  adequacy  of 
requirements,  and  the  ability  of  the  program  to  meet  performance 
goals  in  operational  effectiveness  and  suitability.  OAs  can  be 
made  at  any  time  using  technology  demonstrators,  prototypes, 
mockups,  or  simulations,  but  do  not  substitute  for  the  IOT&E 
necessary  to  support  FRP  decisions.  An  OA  does  not  have  to  use 
production  representative  articles.  An  MDAP  or  OSD  designated 
T&E  oversight  program  requires  an  OA  to  support  a  LRIP  decision. 
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and  can  support  other  program  reviews.  All  OAs  to  include  those 
contained  within  integrated  test  plans  should  be  identified  in 
the  TEMP.  For  programs  on  the  OSD  T&E  oversight  list,  the  OA 
test  plans  require  formal  approval  by  DOT&E.  OAs  do  not  support 
VCDs,  FRP  DRs,  fleet  release  or  introduction  recommendations. 

4. 7. 2. 1.2  OT-A  (EOAs) 

Early  operational  assessments  (EOAs)  are  conducted  during 
the  materiel  solution  analysis  and  Technology  Development  phases 
to  support  Milestone  B.  Tests  should  employ  advanced  development 
models  (ADMs) ,  prototypes,  brass-boards,  or  surrogate  systems, 
but  may  be  limited  to  virtual  models.  The  primary  objectives  of 
an  EOA  are  to  provide  early  identification  of  risk  areas  and 
projections  for  enhancing  features  of  a  system.  An  OT-A  (EOA) 
should  be  considered  for  ACAT  I  and  II  programs,  other  programs 
receiving  DOT&E  oversight,  and  other  ACAT  programs,  as 
appropriate . 

4. 7. 2. 1.3  OT-B  (OA) 

OT-B  is  the  OA  conducted  during  the  engineering  and 
manufacturing  development  (EMD)  phase.  For  most  ACAT  I  and  OSD 
DOT&E  oversight  programs,  at  least  one  OA  is  a  prerequisite  for 
LRIP.  The  MDA  should  determine  if  OT&E  is  required  prior  to  LRIP 
for  non-OSD  T&E  oversight  programs.  If  there  are  two  or  more 
phases  of  OT-B,  the  final  phase  will  support  milestone  C  (LRIP 
approval) . 


4. 7. 2. 1.3.1  DT  Assist 

Whenever  appropriate,  in  order  to  reduce  program  costs, 
improve  program  schedule  and  provide  early  visibility  of 
performance  risk,  COMOPTEVFOR  or  Director,  MCOTEA  may  be  asked  by 
the  PM  to  assist  DT&E.  This  is  a  DT  phase,  under  the  control  of 
the  DA  and  the  requirements  of  DT&E  are  in  effect.  DT  assist  is 
not  a  formal  phase  of  OT&E,  but  rather  a  period  of  DT  in  which  OT 
personnel  are  actively  involved,  providing  operational 
perspective,  and  gaining  valuable  hands-on  familiarity  with  the 
system.  Data  and  findings  from  DT  assist  may  be  used  to 
supplement  formal  OT  data.  DT  assist  does  not  resolve  COIs,  does 
not  reach  conclusions  regarding  operational  effectiveness  or 
suitability,  and  does  not  make  a  recommendation  regarding  fleet 
release.  An  OT&E  test  plan  or  OT&E  final  report  is  not 
generated.  A  letter  of  observation  (LOO)  is  provided  to  the  DA 
upon  request. 

COMOPTEVFOR  and  Director,  MCOTEA  should  participate  in 
DT&E  planning,  monitor  DT&E,  assess  relevant  OT&E  issues,  and 
provide  feedback  to  the  DA  for  DT  assist  periods.  This 
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involvement  in  DT&E  planning  allows  maximizing  the  use  of  DT  data 
by  the  OTA  by  fixing  the  conditions  under  which  DT  data  meets  the 
operationally  realistic  conditions  to  allow  its  use  by  the  OTA 
for  analysis. 

A  memorandum  of  agreement  (MOA)  may  be  developed  between 
COMOPTEVFOR  or  Director,  MCOTEA  and  the  DA  for  all  DT  assisted 
DT&E.  This  MOA  should  address  sharing  of  data,  contractor 
involvement,  and  level  of  feedback  from  the  OTA  to  the  DA. 

4. 7. 2. 1.4  Combined  DT  and  OT 

Combined  DT  and  OT  is  a  period  of  test  in  which  assets  and 
data  are  shared  by  the  DA  and  COMOPTEVFOR  or  Director,  MCOTEA  to 
reduce  program  costs,  improve  program  schedule,  and  provide 
visibility  into  performance  risk  early  in  the  testing  cycle.  If 
the  DA  and  OTA  desire  to  combine  DT  and  OT  such  that  OT  data  is 
obtained,  reference  (a)  OT  requirements  and  OT  requirements  of 
SECNAVINST  5000. 2E,  paragraph  4.7.1,  need  to  be  met.  If  during 
combined  DT/OT  a  dedicated  period  of  OT  is  necessary,  this 
dedicated  period  will  be  exclusively  OT,  generally  near  the  end 
of  the  combined  testing,  and  executed  by  COMOPTEVFOR  or  Director, 
MCOTEA.  A  dedicated  OT  period  permits  the  OTA  to  assess  system 
performance  in  as  operationally  representative  environment  as 
possible.  COMOPTEVFOR  or  Director,  MCOTEA  should  participate  in 
DT&E  planning,  monitor  DT&E,  assess  relevant  OT&E  issues,  and 
provide  feedback  to  the  DA.  Specific  conditions  and 
responsibilities  that  cannot  be  adequately  covered  in  the  TEMP, 
including  the  sharing  of  test  data,  should  be  outlined  via  a  MOA 
between  the  DA  and  COMOPTEVFOR  or  Director,  MCOTEA.  While 
TECHEVAL  and  IOT&E  cannot  be  combined,  operationally  relevant 
TECHEVAL  data  may  be  used  to  supplement  data  collected  during 
IOT&E. 


4. 7. 2. 1.5  OT-C  (IOT&E) / (Navy  OPEVAL) 

IOT&E  is  OT&E  conducted  to  support  a  FRP  decision  by  the 
MDA  or  a  recommendation  by  the  OTA  for  a  fleet  release  or  fleet 
introduction.  It  consists  of  the  OT&E  in  the  Production  and 
Deployment  phase  before  the  FRP  decision. 

Equipment /software  introduced  into  the  tested  system  for 
IOT&E  should  be  production  representative.  See  this  guidebook, 
chapter  4,  paragraph  4. 7. 2. 2,  for  software  IOT&E  requirements. 

The  level  of  system  development  should  be  documented  in  the  TEMP. 
IOT&E  should  commence  upon  the  DA's  certification  of  readiness 
for  OT  or  upon  receipt  of  approval  by  CNO  (N84)  (see  SECNAVINST 
5000. 2E,  chapter  4,  paragraphs  4. 6.4.4  and  4.6.6)  when  required 
due  to  waiver  or  deferral.  The  time  allotted  between  completion 
of  IOT&E  and  the  full-rate  production  decision  review  should 


4-58 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


allow  adequate  time  (normally  90  days  for  ACAT  I  and  II  programs, 
and  60  days  for  ACAT  III  and  IVT  programs)  for  preparing  the 
evaluation  report  by  COMOPTEVFOR  and  additional  days  (normally 
45)  for  review  by  OSD  DOT&E  plus  any  additional  time  required  by 
the  DA  to  plan  for  discrepancy  correction.  If  production  or 
fleet  introduction  is  not  approved  at  full-rate  production 
decision  review,  subsequent  T&E  should  be  identified  as  further 
phases  of  DT-C  and  OT-C.  If  the  system  is  approved  for 
acquisition  of  additional  LRIP  quantities  because  significant 
deficiencies  remain,  CNO  may  schedule  an  additional  phase  of 
IOT&E . 

4. 7. 2. 1.6  Follow-on  Operational  Test  and  Evaluation 
(FOT&E)  '  * 

FOT&E  is  all  OT&E  conducted  after  the  final  phase  of 

IOT&E. 


4. 7. 2. 1.6.1  OT-D 

OT-D  is  OT  conducted  after  the  FRP  decision.  OT-D  is 
conducted,  if  appropriate,  to  evaluate  correction  of  deficiencies 
in  production  systems,  to  complete  deferred  or  incomplete  IOT&E, 
and  to  continue  tactics  development. 

4. 7. 2. 1.6. 2  OT-E 

OT-E  should  be  scheduled  and  conducted  to  evaluate 
operational  effectiveness  and  suitability  for  every  program  in 
which  production  models  have  not  undergone  previous  OT&E. 

4. 7. 2. 1.6. 3  Verification  of  Corrected  Deficiencies 
(VCD)  for  Navy  Programs 

While  specific  OT  report  tracking  and  response  mechanisms 
are  not  required,  programs  should  review  OT  reports  and  formally 
respond  with  plans  for  addressing  or  deferring  the  correction  of 
deficiencies.  The  purpose  of  VCD  is  to  confirm  correction  of 
deficiencies  identified  during  IOT&E  or  FOT&E.  This  evaluation 
should  apply  to  only  those  deficiencies  that  have  been  corrected. 
VCD  can  occur  through  COMOPTEVFOR  review  and  endorsement  of 
corrective  actions  or,  in  some  cases,  through  an  end-to-end  test 
of  the  complete  system,  depending  on  the  complexity  of  the  system 
and  the  extent  of  the  deficiencies.  Where  retest  of  deficiencies 
is  required,  a  VCD  can  occur  as  part  of  formal  FOT&E  or  as  a 
specific  test  limited  to  the  verification  effort.  The  DA  should 
submit  VCD  requests  to  COMOPTEVFOR  with  an  information  copy  to 
CNO  (N84) .  The  TEMP  need  not  be  updated  or  revised  prior  to  a 
VCD.  Rather,  the  VCD  and  its  results  should  be  incorporated  in 
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the  next  scheduled  TEMP  update  or  revision.  The  VCD  request  to 
COMOPTEVFOR  from  the  DA  should  identify  the  deficiency ( ies ) 
corrected . 

An  OTRR  is  not  required  prior  to  commencing  a  VCD. 

4. 7. 2. 1.7  OT  Resource  Requirements 

To  avoid  cost  growth,  the  OTA  should  advise  the  DA  of  OT&E 
resource  requirements  early  in  test  planning  and  prior  to  TEMP 
approval.  When  resource  requirements  cannot  be  specified  prior 
to  TEMP  approval,  a  time  and/or  methodology  should  be  provided  to 
complete  resource  requirements  for  test.  The  OTA  should  maintain 
continuous  close  liaison  with  the  PM  and  DA  over  the  life  of  the 
program.  For  Navy  programs,  CNO  (N84)  resolves  issues  when  there 
is  a  disagreement  between  the  DA  and  the  OTA. 

4. 7. 2. 2  OT  of  Computer  Software 

Computer  software  presents  unique  OT  challenges. 

Successful  programs  are  following  the  methodology  and  philosophy 
herein  to  develop  their  software  testing  programs. 

Within  its  lifecycle,  software  development  and  deployment 
can  be  broken  into  two  categories: 

a.  New  Developments  that  represent  or  will  represent  the 
first  fielded  version  of  the  software,  which  will  be  called 
herein  the  baseline  or  core  increment;  and 

b.  Revisions  to  the  baseline  that  are  or  will  be  fielded, 
which  will  be  called  herein  increments  one,  two,  etc.  in 
sequential  order  of  development.  Any  software  code  modification, 
no  matter  how  minor,  will  be  considered  a  revision  to  allow 
management  of  OT  configurations  as  needed. 

Software  works  within  a  hardware/sof tware  construct,  which 
includes  the  computer  hardware  that  executes  the  software,  and 
other  hardware  and  software  with  which  the  software  interacts  or 
affects.  Herein  this  construct  is  called  a  configuration. 

Any  changes  to  the  hardware  or  software  in  the  construct 
changes  the  configuration  and  is  a  key  factor  in  deciding  the 
amount  of  testing  required  for  each  software  revision.  Strong 
configuration  management  is  an  absolute  requirement  for  keeping 
program  risks  and  software  testing  costs  to  a  minimum. 

Typically,  DT  of  software  involves  verification  that  the 
specified  functionality  works  as  contracted  and  that  the  software 
does  not  cause  a  fatal  computer  fault.  However,  even  the  best  DT 
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is  unable  to  fully  test  the  code,  often  follows  non-operational 
test  scenarios  and  may  not  subject  the  system  to  operational 
environmental  stresses.  For  this  reason  as  well  as  for 
regulatory  and  statutory  reasons,  OT  is  required. 

The  subsections  of  this  guidebook  below  address  the  best 
way  to  conduct  operational  software  testing  for  most  acquisition 
systems.  It  is  based  upon  proven  successful  software  testing 
practices  already  in  use  within  DoD.  Director  Operational  Test 
and  Evaluation  Memorandum,  Guidelines  for  Operational  Test  and 
Evaluation  of  Information  and  Business  Systems,  of  14  Sep  2010 
<https : / / extranet . dote . osd . mil /policy . html>  provides  additional 
guidance  on  determining  elements  of  risk,  the  appropriate  level 
of  testing,  and  responsibilities,  often  referred  to  as  risk 
assessment  level  for  operational  test  (RALOT) . 

4. 7. 2. 2.1  Baseline  or  Core  Increment  Testing 

OT  planners  should  examine  and  consider  the  DT  conducted 
in  their  planning  for  OT&E.  They  must  also  know  the  differences 
between  the  DT  configuration  and  the  operational  configuration. 
Assuming  that  the  DT  is  assessed  by  the  OTA  to  have  met  its  goals 
and  the  configuration  differences  are  not  major,  OT  planners 
should  proceed  to  plan  OT&E,  which  permits  assessment  of  the 
software's  effectiveness,  suitability,  and  survivability  in  fully 
realistic  operational  scenarios,  with  real  users,  in  operational 
environments.  Where  DT  is  assessed  by  the  OTA  to  meet  OT  data 
needs,  actual  OT  may  be  reduced  as  appropriate.  It  is  emphasized 
that  the  decision  to  use  or  not  use  DT  data  is  that  of  the  OTA, 
not  the  DA. 


4. 7. 2. 2. 1.1  Mission  Criticality  and  Software  Risk 
Based  Operational  Testing 

Just  as  DT&E  cannot  exhaustively  test  software  for  all 
conditions,  neither  can  OT&E.  Given  this  reality,  OT&E  must 
follow  a  methodology  that  focuses  first  and  foremost  on  the 
primary  concerns  of  the  operational  user  with  attention  given  to 
secondary  concerns  as  time  and  resources  permit. 

The  most  accepted  software  OT&E  methodology  within  DoD  is 
to  prioritize  software  testing  in  order  of  highest  mission 
criticality  and  highest  software  risk. 

Software  risk  (SR)  is  characterized  by  what  is  known  about 
its  functionality  and  reliability.  If  software  is  known  by 
previous  operational  experience  and  testing  to  properly  function 
and  be  reliable  then  the  risk  is  low. 

Mission  criticality  (MC)  is  characterized  by  the  impact  of 
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software  failure  on  operational  mission  success.  If  software 
failure  could  cause  mission  failure,  the  MC  is  high. 

Combining  these  two  concepts,  software  that  has  high  MC 
and  high  SR  should  be  tested  as  thoroughly  as  possible.  On  the 
other  hand,  the  need  to  thoroughly  test  software  with  a  low  MC 
and  low  SR  is  less  urgent.  Additional  guidance  on  how  to  apply 
these  concepts  in  a  manner  acceptable  to  test  approval 
authorities  is  found  in  Director  Operational  Test  and  Evaluation 
Memorandum,  Guidelines  for  Operational  Test  and  Evaluation  of 
Information  and  Business  Systems,  of  14  Sep  2010 
<https : / / extranet .dote.osd.mil/policy. html> . 

4. 7. 2. 2. 2  Revision  or  post  Core  Increment  Testing 

Testing  software  revisions  to  a  baseline  follows  the  same 
methodology  as  for  baseline  or  previous  increment  testing.  The 
only  expected  difference  is  in  the  level  of  risk  assigned  to  the 
software.  Because  there  should  be  some  increased  knowledge  of 
and  therefore  increased  level  of  confidence  in  the  software 
functionality  and  reliability,  the  level  of  OT&E  may  be  tailored 
further  than  in  baseline  or  previous  increment  OT&E.  However 
this  could  be  offset  by  configuration  changes.  OT  planners  must 
carefully  examine  how  a  software  increment  differs  from  its 
predecessor  as  well  as  any  configuration  changes  before  reducing 
the  scope  of  OT&E.  Again  the  effect  on  mission  success  should 
the  software  increment  fail  must  play  a  role  in  deciding  the 
scope  of  OT&E. 

4. 7. 2. 2. 3  Use  of  Non-Operational  Facilities 

Use  of  non-operational  facilities  (e.g.,  LBTS)  to  conduct 
part  or  all  of  OT  is  encouraged.  To  the  extent  that  such  a 
facility  fully  replicates  the  operational  environment  in  all 
details,  data  derived  therein  may  be  used  by  the  OTA  for  OT&E 
purposes.  Where  there  are  differences  to  the  complete 
operational  environment,  OT  must  be  conducted  in  the  intended 
operational  environment  when  physically  possible  to  assess  those 
differences.  By  operational  environment  replication,  it  is  meant 
to  include  such  factors  as  size,  shape,  air  conditioning,  power 
fluctuations,  and  any  other  physical  factor  that  causes  the 
facility  not  to  fully  replicate  the  actual  operational 
environment.  Further,  human  factor  differences  must  be  evaluated 
as  well.  For  instance,  the  test  operators  should  be  actual 
military  operators  of  the  same  training,  ranks,  rates, 
backgrounds,  and  abilities  as  found  in  the  operational 
environment.  Well-documented,  strong  configuration  management  of 
such  facilities  is  necessary  to  allow  their  use  in  OT&E. 

4. 7. 2. 2. 4  Use  of  Modeling,  Simulation,  and  Signal 
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Stimulation  in  Software  Testing 

Modeling  and  simulation  (M&S)  may  be  used  for  operational 
test  planning  and  justification  by  the  OTA  for  limiting  the  scope 
of  OT&E  but  cannot  be  used  in  lieu  of  OT&E.  Use  of  M&S  to 
augment  OT&E  results  should  be  limited  to  those  cases  where 
actual  OT&E  cannot  be  conducted  by  law  or  by  limitations  in 
testing  technology  or  resources. 

Use  of  artificial  signals  or  data  to  simulate  real  world 
operational  inputs  in  support  of  software  OT&E  is  permitted  when, 
in  the  opinion  of  the  OTA,  real  world  data  or  signals  cannot  be 
obtained  in  a  manner  to  support  OT&E  objectives,  resources,  or 
time  limits. 

Use  of  M&S  or  artificial  signals  or  data  in  support  of 
OT&E  planning  or  results  should  be  documented  in  the  OT&E  report. 
All  M&S  used  to  support  OT&E  should  meet  V&V  standards  of 
reference  (c)  and  be  accredited  by  the  OTA  for  its  specific  use. 

4. 7. 2. 2. 5  Use  of  Non-Operational  Test  Agency  (OTA) 
Testers  to  Conduct  OT&E 


The  OTA  is  encouraged  to  consult  and  use  software  experts 
and  non-resident  software  testing  resources  as  required  to  plan 
for  or  to  satisfy  OT&E  objectives.  This  includes  use  of  software 
testing  tools.  However,  reliance  on  outside  expertise  and  tools 
to  interpret  OT  results  or  to  conduct  OT  must  be  limited  to  those 
cases  where  the  OTA  lacks  the  resources  to  do  otherwise  and  must 
be  documented  in  the  OT&E  report.  Reliance  on  tools,  models,  and 
expert  opinions  is  more  in  the  domain  of  DT&E.  OT&E  must 
remained  focused  on  how  a  system  actually  works  in  the  real 
world,  not  how  it  is  predicted  to  work  by  tools,  models,  or 
experts . 


4. 7. 2. 2. 6  Role  of  the  Developing  Activity  (DA)  and  the 
OTA  in  OT&E  of  Software 


The  OTA  is  responsible  to  conduct  OT&E  of  software  in  as 
realistically  a  manner  as  is  possible.  The  OTA  is  encouraged  to 
tailor  OT&E  and  especially  OT&E  in  the  actual  operational 
environment  as  suggested  in  this  guidebook  and  by  other  DoD 
regulations,  instructions,  and  guidance.  However,  for  the  OTA  to 
tailor  OT&E  of  software,  he  must  have  proof  that  such  tailoring 
is  defensible. 

The  DA  is  responsible  for  providing  all  the  information 
required  by  the  OTA  to  make  a  determination  of  how  and  to  what 
extent  he  may  tailor  OT&E. 
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The  best  way  to  optimize  software  testing  is  for  the  DA 
and  OTA  to  meet  early  and  often  to  establish  and  refine  software¬ 
testing  criteria  and  to  establish  and  refine  data  requirements 
necessary  to  permit  tailoring  software  tests. 

4. 7. 2. 2. 7  Designation  of  Software  Testing  and  Software 
Qualification  Testing  (SQT) 

When  a  software  revision  or  increment  is  to  be  released  as 
part  of  an  acquisition  milestone  decision,  the  OT  is  considered 
to  be  an  OA  or  IOT&E.  When  a  software  revision  or  increment  is 
to  be  released  not  in  conjunction  with  a  milestone  decision,  it 
may  be  designated  a  software  qualification  test  (SQT) . 

4. 7. 2. 2. 8  Software  Operational  Testing  and 
Interoperability,  Security,  or  Information  Assurance 
Certification 


Various  organizations  have  been  established  to  "certify" 
or  "accredit"  software  for  interoperability,  security,  or  IA. 
Certification  or  accreditation  of  software  by  an  outside  agency 
or  authority  does  not  absolve  the  OTA  from  operationally  testing 
and  assessing  software  for  interoperability,  security,  or  IA.  As 
with  DT  data,  the  OTA  is  encouraged  to  consider  and  use 
certification  or  accreditation  data  to  assist  in  their 
assessments  and  to  tailor  OT&E  accordingly,  but  the  use  of  such 
data  must  be  defensible  as  being  operationally  as  realistic  as 
possible.  Whether  to  use  certification  or  accreditation  data  in 
support  of  or  in  lieu  of  some  OT&E  is  the  decision  of  the  OTA. 

4. 7. 2. 2. 9  Changes  to  Software  Operational  Requirements 

Operational  testers  assess  software  for  effectiveness, 
suitability,  and  survivability  in  conformity  with  the  approved 
operational  requirement  for  the  software  documented  in  the  ICD, 
the  CDD,  and  the  CPD  or  their  predecessors,  the  mission  needs 
statement  (MNS)  and  the  operational  requirements  document  (ORD) . 
The  TEMP  is  the  formal  agreement  regarding  what  to  test,  when, 
and  with  what  resources. 

The  situation  sometimes  arises,  and  is  expected  to  occur 
more  often  with  evolutionary  acquisition,  where  a  software 
revision  adds  capability  not  addressed  in  the  formal  capabilities 
(requirements)  documents  or  deletes  or  defers  formal  capabilities 
needs.  When  such  a  change  adversely  affects  the  formal 
capability  need  in  a  significant  way  then  the  formal  capabilities 
documents  and  TEMP  should  be  modified  and  approved  accordingly. 
Note  that  any  changes  to  software  operational  capabilities 
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require  an  assessment  for  human  systems  integration  (HSI)  and 
doctrine,  organization,  training,  materiel,  leadership  and 
education,  personnel,  facilities,  and  policy  (DOTMLPF-P) 
implications.  The  implications  for  each  increment  should  be 
identified,  planned,  documented,  and  accepted  by  CNO  (Nl)  and  CNO 
(N15)  prior  to  formal  approval  of  revisions  to  operational 
capabilities  documents.  When  such  a  change  does  not  adversely 
affect  the  formal  requirement  in  a  significant  way,  then  the 
operational  testers  may  accept  a  statement  of  functionality  (SOF) 
approved  by  the  appropriate  resource  sponsor,  as  the  basis  for 
modifying  the  OT  plan  objectives.  The  OT  report  should  note  the 
requirement  and  test  modification  and  its  approval  by  the 
resource  sponsor. 

4. 7. 2. 2. 9.1  Statement  of  Functionality  (SOF) 

The  SOF  is  normally  prepared  by  the  PM  for  use  by  the  OTA  and 
routed  via  the  PM' s  chain  of  command  through  the  Resource  Sponsor 
(to  include  coordination  with  CNO  (Nl)  and  CNO  (N15) )  to  CNO 
(N84)  for  approval  for  Navy  programs.  The  SOF  should  include  as 
a  minimum: 

a.  The  additions,  deletions,  and  modifications  to  the 
software  capability; 

b.  The  reason  for  making  the  changes  and  not  following 
the  formal  requirements  plan  and  delivery  schedule; 

c.  How  the  additions,  deletions,  or  modifications  affect 
the  overall  satisfaction  of  mission  need  in  the  formally  stated 
requirement ; 

d.  Why  a  formal  change  to  the  capabilities  documents  or 
TEMP  is  not  considered  necessary; 

e.  How  the  additions,  deletions,  or  modifications  affect 
KPPs,  CTPs,  COIs,  or  Measure  of  Effectiveness  (MOE)  in  existing 
capabilities  documents  and  TEMPs/Test  Plans,  and  why  this  is 
acceptable;  and 

f.  Additional  testing  requirements  or  concerns  raised  by 
the  additions,  deletions,  or  modifications  that  should  be 
factored  in  the  test  planning  or  execution. 

4.7.2.2.10  System  of  Systems  Testing 

The  DoD  is  investing  tremendous  effort  into  the 
development  and  fielding  of  software  intensive  systems  that  work 
in  a  single  net-centric  continuum  (e.g.,  FORCEnet  and  the  global 
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information  grid  (GIG) ) .  The  issue  arises  as  to  how  to  test  a 
system  that  must  connect  and  become  a  part  of  a  larger  SoS .  DoD 
and  DON  guidance  is  evolving  but  leaves  no  doubt  that  such 
systems  must  be  operationally  effective,  suitable,  and  survivable 
in  the  SoS. 

The  threat  of  the  use  of  our  net-centric  systems  against 
us  by  potential  enemies  makes  the  effectiveness  of  both 
information  assurance  (IA)  and  system  security  an  important  COI 
for  test  planners  to  address.  Not  only  must  each  new  system 
attached  to  the  net  be  operationally  effective  and  suitable  in 
its  own  right,  it  must  also  be  proven  to  not  create  an  IA  threat 
to  the  net  by  enemy  action.  That  enemy  action  is  not  only  an 
external  one  but  also  an  internal  one.  IA  threats  are  emerging 
that  show  the  need  to  have  system  protections  in  depth  against 
agents  both  outside  and  inside  system  security  boundaries  and 
protocols . 

OT  planners  should  focus  their  testing  of  systems  that 
connect  to  SoS  as  follows. 

a.  Assess  the  system's  operational  effectiveness, 
suitability,  and  survivability  per  the  overall  guidance  of  this 
chapter  on  software  testing; 

b.  Assess  the  system's  interoperability  with  the  SoS  in 
mission  critical  operational  scenarios.  Limit  assessment  of 
potentially  adverse  impacts  on  the  SoS  by  the  system  to  this 
interoperability  testing;  and 

c.  Assess  the  IA  vulnerability  posed  by  the  system  on  the 
SoS  in  operationally  realistic  scenarios.  Assume  that  the  system 
or  its  portal  to  the  SoS  is  the  source  of  the  attack.  Look  at 
attacks  coming  through  the  portal  to  the  system  and  from  the 
system  through  the  portal  to  the  SoS.  Do  not  try  to  assess  in 
what  manner  the  SoS  could  be  impaired  by  an  attack  but  simply 
report  the  vulnerability. 

Cryptographic  systems  used  to  protect  systems  or  the  SoS 
should  be  assumed  to  be  secure  but  their  potential  capture  or  use 
by  inside  hostile  agents  as  a  means  to  conduct  information 
warfare  attacks  on  either  the  system  or  through  the  system  to  the 
SoS  should  be  operationally  evaluated.  If  in  the  course  of 
testing,  cryptographic  security  issues  become  evident,  they 
should  be  immediately  addressed  to  NSA  through  proper  DON  and  DoD 
channels  and  to  CNO  (N84)  for  adjudication. 

SoS  testing  guidance  is  undergoing  continual  evaluation 
and  development.  Data,  results,  conclusions,  opinions,  and 
recommendations  concerning  this  testing  guidance  and  SoS  testing 
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in  general  should  be  sent  to  Test  and  Evaluation  Division  (OPNAV 
(N842))  for  consideration  in  the  update  to  both  T&E  policy  and 
recommendations  in  this  guidebook. 

4.7.2.2.11  Resolution  of  Disputes  involving 
Operational  Testing  of  Software 

Disagreements  between  parties  involved  in  software  test 
planning  and  execution  (e.g.  DA,  resource  sponsor,  OTA,  etc.) 
should  be  resolved  primarily  through  the  T&E  WIPT.  Navy  programs 
may  seek  interpretation  of  test  policy  from  CNO  (N84)  or  Test  and 
Evaluation  Division  (OPNAV  (N842)). 

Should  the  T&E  WIPT  not  resolve  an  issue,  the  parties 
involved  should  request  adjudication  by  the  TECG  for  Navy 
programs  or  the  IPPD  process  for  Marine  Corps  programs. 

4.7.3  Operational  Test  (OT)  for  Configuration  Changes 

[from  SNI  5000.2E,  4.7.3:  The  DA  shall  ensure  the  T&E 
planning  includes  OT&E  for  significant  configuration  changes  or 
modifications  to  the  system.  OT&E  events  are  necessary  for  the 
OTA  to  substantiate  a  Navy  and  Marine  Corps  release  and 
introduction  recommendation  to  the  CNO  and  CMC  for  all  such 
system  changes .] 

See  paragraphs  4. 7. 2. 2. 2,  4. 7. 2. 2. 9,  and  4. 7. 2. 2. 9.1  in 
this  guidebook. 

4.7.4  OT  for  Information  Assurance 

[ from  SNI  5000. 2E ,  4.7.4:  All  weapon ,  C4ISR,  and  IT 
programs  shall  be  tested  and  evaluated  for  appropriate 
application  of  IA  (reference  (a) ) .  Systems  shall  incorporate  IA 
controls  identified  in  reference  (f) ,  based  upon  the  objective  of 
MAC  and  confidentiality  level.  IA  controls  shall  be  evaluated 
for  adequacy  and  the  appropriate  authority  to  operate  approval 
shall  be  verified  prior  to  entering  OT.  The  OTA  shall  evaluate 
operational  IA  vulnerabilities  and  capabilities ,  to  include  the 
capability  to  protect  and  restore  data  and  information,  and  to 
detect  and  react  based  on  DIA/TAC  validated  IA  threats  per 
reference  (e)  and  (t)  .] 

See  paragraphs  4. 7. 2. 2. 8  and  4.7.2.2.10  in  this  guidebook. 

4.7.5  Quick  Reaction  Assessment  (QRA) 

[from  SNI  5000. 2E,  4.7.5:  When  an  urgent  operational  need 
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is  identified  for  a  system  in  development  or  when  a  system  has 
been  granted  RDC  or  RDD  status  (as  defined  in  chapter  1, 
paragraph  1.8)  by  ASN (RDA) ,  it  may  be  necessary  to  modify  the 
established  OT  process  to  rapidly  deliver  that  capability  to  the 
fleet.  In  such  cases,  the  program  sponsor  may  obtain  an  OTA 
assessment  of  operational  capabilities ,  limitations ,  and 
considerations  for  deploying  the  system.  Navy  program  sponsors 
may  request  a  QRA  from  CNO  (N84)  .  XJSMC  program  sponsors  may 
request  a  QRA  from  Director ,  MCOTEA.  When  approved,  COMOPTEVFOR 
or  Director ,  MCOTEA  should  conduct  the  assessment  and  issue  a 
report  as  soon  as  possible .  The  following  information  should  be 
included  in  the  QRA  request: 

a.  The  purpose  of  the  assessment  and,  specifically,  what 
system  attributes  the  program  sponsor  wants  assessed ; 

b.  The  length  of  time  available  for  the  assessment; 

c.  The  resources  available  for  the  assessment;  and 

d.  Which  forces  will  deploy  with  the  system  prior  to  IOC. 

For  an  RDD  system  the  OTA  shall  assess  the  need  for  a  QRA 
and  provide  a  recommendation  in  writing  to  the  PEO,  SYSCOM,  or 
DRPM  charged  with  developing  a  test  plan  for  the  RDD  system. 

QRAs  do  not  obviate  or  replace  scheduled  OT  in  an  approved 
TEMP  for  acquisition  programs.  Systems  in  RDC  or  RDD  status  that 
have  completed  QRA  will  normally  undergo  formal  OT  when  they 
transition  to  program  status .] 

4.7.6  OT&E  Information  Promulgation 

[from  SNI  5000. 2E,  4.7.6:  See  reference  (a),  enclosure  6, 
and  this  chapter,  paragraph  4.11,  T&E  Reports,  for  information 
promulgation  requirements  for  all  DON  ACAT  programs  requiring 
OT&E. ] 


4. 7. 6.1  Milestone  Decision  Authority  (MPA)  Briefing 

[from  SNI  5000. 2E,  4. 7.  6.1:  See  reference  (a),  enclosure 
6,  for  implementation  requirements  for  DON  ACAT  I  and  IA  programs 
and  programs  on  the  OSD  T&E  oversight  list.  The  OTA  will  brief 
the  results  of  program  OTs  at  MDA  decision  meetings .] 

4 . 7 . 6 . 2  OT  Data  Release 
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The  OTA  should  release  valid  data  and  factual  information 
in  as  near  real-time  as  possible  to  the  DA.  Data  may  be 
preliminary  and  should  be  identified  as  such.  Evaluative 
information  should  not  be  released  until  the  OTA  has  completed 
its  evaluation  and  issued  a  final  report.  Anomaly  reports  and 
deficiency  reports  will  be  issued  as  explained  in  this  guidebook, 
chapter  4,  paragraph  4.11.1.2.  The  logistics  of  releasing  data 
should  not  interfere  with  test  events,  analysis,  or  report 
preparation . 

4.7.7  Use  of  Contractors  in  Support  of  OT&E 

[from  SNI  5000. 2E,  4.7.7:  See  reference  (a),  enclosure  6, 
for  implementation  requirements  for  DON  ACAT  programs  requiring 
OT&E. ] 

4.7.8  Visitors 

[ from  SNI  5000. 2E,  4.7.8:  During  operational  testing , 
observers  and  other  visitors  are  authorized  at  the  discretion  of 
COMOP TEVFOR ,  or  Director,  MCOTEA,  as  appropriate.] 

Note  that  per  reference  (u) ,  visit  clearances  through  the 
foreign  visits  systems  are  required  for  foreign  national 
observers  or  visitors  to  government  facilities. 

4.7.9  Special  T&E  Considerations 

4. 7. 9.1  T&E  of  Modifications 

The  recommendations  of  COMOPTEVFOR,  the  DA,  the  CNO  resource  and 
program  sponsor  (s),  and  INSURV  and  DASN (RDT&E)  CHSENG  (both  where 
applicable)  should  be  considered  in  a  T&E  WIPT  forum,  as 
described  in  paragraph  4.4.3  of  this  guidebook,  in  determining 
the  scope  of  testing.  CNO  (N84)  should  adjudicate  unresolved 
issues  concerning  testing  of  modified  systems  and  software.  See 
also  paragraph  4.7.3  above. 

4. 7. 9. 2  T&E  of  Non-Developmental  I terns /Commercial - 
Off-The-Shelf  (NDI/COTS) 


Prior  to  an  NDI  or  COTS  acquisition  decision,  the  DA,  with 
the  concurrence  of  COMOPTEVFOR  or  Director,  MCOTEA,  should  assess 
the  adequacy  of  any  previously  conducted  DT&E,  OT&E,  contractor, 
or  other  source  data  and  provide  recommendations  to  CNO  (N84)  or 
CMC  (DC,  CD&I)  on  the  need  for  additional  T&E  requirements.  When 
the  procurement  of  a  system  developed  or  tested  by  a  non-DON  DA 
is  being  planned,  a  memorandum  of  understanding  (MOU)  between  the 
activities  involved  should  address  the  acceptance  of  prior  T&E 
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results.  A  key  consideration  in  COTS  integration  is  to  validate 
the  components  meet  the  specified  reliability  and  maintainability 
performance  requirements  in  the  intended  operational  environment. 
If  additional  T&E  is  required,  the  DA  should  initiate  a  TEIN 
request . 


4. 7. 9. 3  Extension  of  Application 

An  extension  of  application  eliminates  the  requirement  for 
IOT&E  or  OPEVAL  by  COMOPTEVFOR  or  Director,  MCOTEA  for  the  common 
system,  subsystem,  or  equipment  that  have  previously  undergone 
IOT&E  in  other  platforms,  systems,  etc.  Concurrence  of  the 
suitability  of  extension  of  application  should  be  obtained  via 
the  OTA.  Extension  of  application  does  not  eliminate  the  need  to 
obtain  fleet  introduction  approval  from  the  program  sponsor.  A 
period  of  FOT&E  should  be  considered  to  verify  that  integration 
of  the  system,  subsystem,  or  equipment  into  the  host  platform  has 
not  degraded  performance.  Following  FOT&E,  the  program  sponsor 
should  determine  if  full  fleet  introduction  or  installation  is 
appropriate . 

4 . 8  Annual  Office  of  the  Secretary  of  Defense  (OSD)  T&E  Oversight 
List 


[from  SNI  5000. 2E,  4.8:  The  annual  OSD  T&E  oversight  list 
identifies  those  DON  programs  subject  to  OSD  T&E  oversight .  ACAT 
I,  II,  and  programs  requiring  LFT&E  are  generally  included  in 
oversight.  Other  programs  that  generate  Congressional ,  public, 
or  special  interests  are  routinely  included  in  the  listing.  DON 
T&E  information  related  to  programs  on  the  OSD  oversight  list 
will  be  coordinated  through  CNO  (N84)  for  Navy  programs.  PMs  for 
XJSMC  programs  subject  to  OSD  T&E  oversight  will  coordinate  DT 
information ,  and  Director ,  MCOTEA,  will  coordinate  OT 
information . ] 

4 . 9  Live-Fire  Test  and  Evaluation  (LFT&E) * 


[ from  SNI  5000.2E,  4.9:  The  DA  is  responsible  for  LFT&E 
strategy  development,  associated  TEMP  input,  monitoring,  and 
supporting  the  conduct  of  LFT&E .  Per  reference  (a) ,  DOT&E  shall 
approve  the  LFT&E  strategy  for  programs  covered  by  statute  prior 
to  the  decision  to  enter  into  EMD  (normally  milestone  B) .  For 
USMC  programs  not  required  by  statute  to  conduct  LFT&E,  but  where 
LFT&E  is  appropriate,  the  Director ,  MCOTEA,  shall  concur  with  the 
LFT&E  strategy  as  approved  by  the  MDA  in  the  TES  or  TEMP. 

Per  section  2366  of  title  10,  U.S.C.,  realistic 
survivability  and  lethality  testing  shall  be  completed,  the 
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report  submitted ,  and  results  considered ,  prior  to  making  a 
beyond  LRIP  decision . 

Survivability  and  lethality  tests  required  by  statute  must 
be  completed  early  enough  in  EMD  phase  to  allow  correction  of  any 
design  deficiency  before  proceeding  beyond  LRIP. 

LFT&E  events  deemed  necessary  prior  to  milestone  B  may  be 
conducted  under  a  stand-alone  plan  (in  lieu  of  an  approved  TEMP) . 
The  intention  of  this  policy  is  to  facilitate  agreement  between 
developers  and  oversight  agencies .  This  stand-alone  plan  for 
pre -miles tone  B  LFT&E  events  will  follow  the  same  approval 
process  as  prescribed  for  a  TEMP.  The  stand-alone  plan  should  be 
limited  in  scope  and  address  only  objectives  of  pre-milestone  B 
LFT&E  events.  Subsequently,  the  stand-alone  plan  should  be 
integrated  into  the  TEMP. 

Each  program  increment  or  modification  requires  a  review 
for  LFT&E  requirements.  If  such  requirements  are  found  to  exist, 
they  must  be  addressed  through  the  TEMP  process. 

See  reference  (a) ,  enclosure  6,  for  implementation 
requirements  for  a  program  that  is  a  covered  major  system,  a 
major  munitions  program,  a  missile  program,  or  a  product 
improvement  (modification)  thereto.  A  covered  major  system  means 
a  vehicle,  weapon  platform,  or  conventional  weapon  system  that 
provides  some  degree  of  protection  to  users  in  combat  and  is  a 
major  system  per  section  2302(5)  of  title  10,  U.S.C.  A  major 
munitions  program  means  a  program  that  is  planning  to  acquire 
more  than  a  million  rounds  or  is  a  conventional  munitions  program 
that  is  a  major  system. 

*Not  applicable  to  ACAT  I A  programs.] 

4.9.1  LFT&E  of  Ships 

For  ships,  the  qualification  of  the  survivability  baseline 
is  conducted  during  construction  and  shakedown.  During 
construction,  tests  and  inspections  confirm  the  achievement  of 
compliance  with  the  requirements  of  the  shipbuilding 
specification  in  the  areas  of  shock  hardening,  air  blast 
hardening,  fire  containment,  damage  control  features,  structural 
hardening,  and  chemical,  biological,  and  radiological  (CBR) 
protection.  During  the  1-year  shakedown  period  following 
delivery  of  the  lead  ship  of  a  class,  or  early  follow  ship  as 
determined  per  reference  (v) ,  a  full-ship  shock  trial  should  be 
conducted  to  identify  any  unknown  weakness  in  the  ability  of  the 
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ship  to  withstand  specified  levels  of  shock  from  underwater 
explosions . 

4.10  Comparative  Testing 

4.10.1  Programs  Defined  by  Statute 

[ from  SNI  5000. 2E,  4.10.1:  Sections  2350a (g)  and  2359b  of 
Title  10,  XJ.S.C.  establish  two  programs:  the  Foreign  Comparative 
Testing  (FCT)  Program  and  the  Defense  Acquisition  Challenge 
Program  (DACP) .  The  FCT  program  tests  allied  or  friendly 
nations'  defense  equipment,  munitions,  and  technologies  to  see  if 
they  can  satisfy  DoD  needs.  DACP  allows  non-DoD  entities  to 
propose  technologies ,  products ,  or  processes  to  existing  DoD 
acquisition  programs.  At  the  OSD  level,  both  FCT  and  DACP  are 
managed  by  the  Comparative  Testing  Office  (CTO) 

(http : / /www .  acq.  osd.mil/cto)  under  USD  (AT&L)  DDR&E  and  Deputy 
Under  Secretary  of  Defense  Advanced  Systems  and  Concepts 
(DUSD  (AS&C)  )  .  ] 

The  FCT  program  provides  for  the  test  and  evaluation  of 
foreign  non-developmental  equipment  that  demonstrates  potential 
to  satisfy  an  operational  requirement.  Within  the  DON,  Office  of 
Naval  Research  (ONR)  proposes  and  manages  FCT  projects.  Each 
year  ONR  issues  a  call  for  proposals  to  the  System  Commands 
(MARCORSYSCOM,  NAVAIRSYSCOM,  NAVSEASYSCOM,  SPAWARSYSCOM) . 
Proposals  are  prioritized  by  either  CNO  or  HQ  USMC  prior  to  ONR 
submission  to  DUSD (AS&C) .  ONR  oversees  the  project  management  of 
all  DON  FCT  projects  via  the  System  Commands.  Proximate  project 
management  is  delegated  to  the  Systems  Commands,  who  report  to 
ONR  on  technical,  schedule,  and  financial  status. 

4.10.2  Developing  Activity  Comparative  Testing 
Responsibilities 

[ from  SNI  5000.2E,  4.10.2:  DAs  shall  follow  comparative 
testing  guidance  provided  by  OSD  (CTO) .  Where  comparative 
testing  is  a  major  portion  of  an  acquisition  program,  it  should 
be  included  in  the  TEMP.  Comparative  testing  derived  components 
of  an  acquisition  program  shall  be  treated  like  contractor  non- 
developmental  items.  Acquisition  programs,  that  include 
comparative  testing  derived  items,  are  not  exempt  from  DT,  OT,  or 
LFT&E  provisions  of  this  instruction.  Reference  (a),  enclosure 
6,  provides  DoD  direction  on  comparative  test  programs .] 

4.11  Test  and  Evaluation  Reporting 

[ from  SNI  5000. 2E,  4.11:  This  paragraph  describes 
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mandatory  T&E  reporting  requirements  for  DON  ACAT  programs  as 
indicated  in  subsequent  paragraphs.  Per  reference  (a),  enclosure 
6,  section  2c (7) ,  DOT&E  and  the  Deputy  Director  for  DT&E  {now 
DASD (DT&E) }  and  Office  of  Defense  Systems  (ODS)  in  the  Office  of 
the  USD  (AT&L) ,  shall  have  full  and  timely  access  to  all 
available  developmental ,  operational,  and  LFT&E  data  and 
reports . ] 

4.11.1  DoD  Component  (DON)  Reporting  of  Test  Results 

[from  SNI  5000. 2E,  4.11.1:  See  reference  (a),  enclosure  6, 
for  implementation  requirements  for  DON  ACAT  I,  selected  ACAT 
IAM,  and  other  ACAT  programs  designated  for  DOT&E  oversight . ] 

4.11.1.1  DT&E  Reports 

[from  SNI  5000. 2E,  4.11.1.1:  A  report  of  results  for  all 
DT&E  conducted  in  DON  shall  be  provided  to  the  appropriate 
decision  authority  and  to  the  OTA  as  needed.  For  programs  on  the 
OSD  T&E  oversight  list  subject  to  DOT&E  oversight ,  the  DA  shall 
provide  copies  of  formal  DT&E  reports  to  the  Deputy  Director , 

DT&E  in  the  ODS  in  OUSD  (AT&L)  and  COMOPTEVFOR  and  Director, 
MCOTEA  at  a  pre-agreed  timeframe  prior  to  program  decision  point 
reviews.  Copies  of  DT&E  reports  for  ACAT  I  programs  shall  be 
provided  to  the  Defense  Technical  Information  Center  (DTIC)  with 
the  SF  298  Report  Documentation  Page.  Copies  of  Navy  internal 
DT&E  event  reports  shall  be  forwarded  to  CNO  (N84) ;  the  Deputy 
Director ,  DT&E;  and  ASN (RD&A) .  Unless  otherwise  coordinated, 

DT&E  reports  shall  be  provided  to  the  OTA  at  least  30  days  prior 
to  start  of  OT.  See  reference  (d)  for  distribution  statements 
required  for  technical  publications  and  reference  (w)  for 
principles  and  operational  parameters  on  DoD  scientific  and 
technical  information  programs.] 

4.11.1.2  OT&E  Reports 

[from  SNI  5000.2E,  4.11.1.2:  COMOPTEVFOR  and  Director, 
MCOTEA  shall  issue  OT  reports  for  ACAT  I  and  IA  programs  within 
90  days  following  completion  of  testing.  All  other  operational 
test  reports  are  due  within  60  days  of  test  completion.  Programs 
subject  to  OSD  T&E  oversight  shall  provide  copies  of  formal  OT&E 
reports  to  DOT&E  per  pre-agreed  timeframe  prior  to  program 
decision  reviews.  When  scheduling  an  FRP  decision  review  DR, 
schedulers  shall  consult  DOT&E  as  to  time  required  to  prepare  and 
submit  the  beyond  LRIP  report.  Copies  of  OT&E  reports  for  all 
ACAT  I  programs ,  except  those  that  contain  vulnerabilities  and 
limitations  data  for  key  war- fighting  systems,  shall  be  provided 


4-73 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


to  the  DTIC  with  the  SF  298.  For  OSD  oversight  program  T&E 
events ,  as  defined  in  the  TEMP,  copies  of  Navy  OT&E  reports  shall 
be  forwarded  via  CNO  (N84)  to  DOT&E  and  DASN (RDT&E)  CHS ENG . 

MCOTEA  shall  distribute  its  report  to  the  ACMC ,  and  upon  release 
to  other  offices  as  appropriate  (for  example,  the  MDA,  PM,  Marine 
operating  forces,  ASN (RD&A) ,  etc.)  and  DOT&E  for  ACAT  I,  selected 
ACAT  IA,  and  other  OSD  T&E  oversight  programs.  See  reference  (d) 
for  distribution  statements  required  for  technical  publications 
and  reference  (w)  for  principles  and  operational  parameters  on 
DoD  scientific  and  technical  information  programs .] 

4.11.1.2.1  Anomaly  Reports 

An  anomaly  report  is  originated  by  COMOPTEVFOR  when  minor 
failures  or  anomalies  are  discovered  during  operational  testing 
that  impact  testing,  but  are  not  so  severe  that  testing  should  be 
stopped.  COMOPTEVFOR  should  report  applicable  data  relating  only 
to  this  anomaly.  The  anomaly  report  is  addressed  to  CNO  (N84), 
the  DA,  and  the  program  sponsor  or  information  technology  (IT) 
functional  area  point  of  contact  (POC)  for  IT  programs. 
COMOPTEVFOR  decides  when  and  if  to  close  a  specific  phase  of  OT&E 
for  which  an  anomaly  report  was  issued. 

4.11.1.2.2  Deficiency  Reports  for  Early  Termination 

A  deficiency  report  is  originated  by  COMOPTEVFOR  when  it 
becomes  apparent  that  the  system  under  OT&E  will  not  achieve 
program  objectives  for  operational  effectiveness  and  suitability, 
is  unsafe  to  operate,  is  wasting  services,  or  test  methods  are 
not  as  effective  as  planned.  COMOPTEVFOR  should  stop  the  test 
and  transmit  a  deficiency  report  to  CNO  (N84),  the  DA,  and  the 
applicable  program  sponsor,  or  the  IT  functional  area  POC.  All 
deficiency  test  data  should  be  provided  to  the  DA  for  corrective 
action.  The  information  should  include  the  configuration  of  the 
system  at  the  time  the  test  was  suspended,  what  specific  test 
section  was  being  conducted,  observed  limitations  that  generated 
the  deficiency  status,  and  any  observations  that  could  lead  to 
identification  of  causes  and  subsequent  corrective  action.  When 
corrected,  the  program  is  recertified  for  OT&E  per  SECNAVINST 
5000. 2E,  chapter  4,  paragraph  4. 6.2.2.  A  re-certification 
message  is  required,  prior  to  restart  of  testing,  addressing  the 
topics  listed  in  SECNAVINST  5000. 2E,  chapter  4,  paragraph  4.6.1. 

4.11.1.3  OT&E  Reporting  Against  the  Threat  of  Record 

From  program  initiation,  it  should  be  understood  that 
threats  evolve  and  the  system  under  development  will  need  to 
perform  against  threats  encountered  at  time  of  fielding.  In 
those  cases  where  the  threat  at  the  time  of  testing  deviates  from 
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the  threat  delineated  in  the  requirements  document,  the  OTA  in 
coordination  with  the  DA  and  sponsor  should  plan  testing  and 
evaluation  that  segregates  report  results.  This  enables  the  MDA 
and  the  CNO  or  CMC  to  have  a  clear  articulation  of  both  the 
system  performance  against  the  programmed  threat  and  what  can  be 
expected  at  Fleet  or  field  introduction.  When  the  value  added  by 
reporting  in  this  manner  is  determined  to  exceed  the  planned 
funding  and/or  schedule  available  for  testing,  the  program  will 
require  deferring  this  testing  until  future  funds  are  programmed 
for  FOT&E  or  evaluation  during  a  Fleet/Field  exercise.  Programs 
on  OSD  OT  oversight  must  anticipate  completing  FOT&E  to  resolve 
title  10  OT&E  obligations. 

4.11.2  LFT&E  Report  for  FRP  DR* 

[from  SNI  5000.2E,  4.11.2:  For  programs  involving  covered 
major  systems,  major  munitions  or  missiles ,  or  product 
improvements  (modifications)  thereto,  the  DA  shall  submit  an 
LFT&E  report  to  DOT&E,  via  CNO  (N84)  or  Director,  MCOTEA,  as 
appropriate.  The  submission  shall  allow  DOT&E  sufficient  time  to 
prepare  an  independent  report  and  submit  it  to  Congress  prior  to 
the  program  proceeding  into  FRP.  PMs  shall  keep  CNO  (N84) 
apprised  of  the  program's  LFT&E  progress  and  execution .  See 
reference  (a) ,  enclosure  6,  for  implementation  requirements  for 
programs  subject  to  LFT&E  statutes . 

*Not  applicable  to  ACAT  I A  programs .] 

4.11.2.1  LFT&E  Waivers* 

[ from  SNI  5000. 2E,  4.11.2.1:  Request  to  waive  full-up 
system-level  live- fire  survivability  and  lethality  testing  must 
be  submitted  by  USD  (AT&L)  for  ACAT  ID  programs  or  ASN  (RD&A)  for 
ACAT  IC  programs  and  below  and  approved  by  DOT&E  prior  to  entry 
into  EMD.  Waiver  requests  not  approved  prior  to  EMD  require 
Congressional  relief  granted  to  SECDEF  on  a  case-by-case  basis. 
Waivers  shall  be  coordinated  with  the  program  sponsor  and  CNO 
(N84)  or  Director ,  MCOTEA,  as  appropriate.  Programs  seeking 
LFT&E  waivers  must  provide  an  alternate  LFT&E  strategy  and  plan 
that  are  acceptable  to  DOT&E. 

*Not  applicable  to  ACAT  I A  programs ] 

4.11.3  Beyond  Low-Rate  Initial  Production  (BLRIP)  Report 

[ from  SNI  5000.2E,  4.11.3:  ACAT  I  programs  and  programs  on 
the  OSD  T&E  oversight  list  designated  by  DOT&E,  shall  not  proceed 
beyond  LRIP  until  the  DOT&E  has  submitted  a  written  report  to  the 
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Secretary  of  Defense  and  the  Congress  as  required  by  section  2399 
of  Title  10,  U.S.C..  See  reference  (a),  enclosure  6,  for  the 
BLRIP  report  for  designated  OSD  T&E  oversight  programs .] 

4.11.3.1  Early  Fielding  or  Interim  BLRIP  Report 

[from  SNI  5000.2E,  4.11.3.1:  For  MDAP  or  DOT&E  oversight 
programs ,  if  a  decision  is  made  to  proceed  to  operational  use  or 
to  make  procurement  funds  available  for  the  program  prior  to  a 
final  decision  to  proceed  beyond  LRIP  (or  limited  deployment  for 
MDAPs  that  are  AISs) ,  DOT&E  is  required  to  submit  the  above 
report,  but  may  decide  to  submit  an  interim  or  partial  report  if 
the  operational  testing  completed  to  date  is  inadequate  to 
determine  operational  effectiveness  and  suitability  and 
survivability .  If  an  interim  or  partial  report  is  submitted,  the 
DOT&E  will  prepare  and  submit  the  required  final  BLRIP  report  as 
soon  as  possible  after  a  final  IOT&E  report  is  provided. ] 

4.11.4  Director,  Operational  Test  and  Evaluation  (DOT&E) 

Annual  Report 

[ from  SNI  5000.2E,  4.11.4:  DOT&E  prepares  an  annual  report 
of  programs  subject  to  OT&E  on  the  OSD  T&E  oversight  list  and  all 
programs  covered  by  LFT&E  during  the  preceding  fiscal  year.  The 
report  covers  basic  program  description,  T&E  activity,  and 
provides  the  Director's  assessment  of  the  T&E.  OPNAV  (N842) 
coordinates  efforts  to  review  and  validate  factual  information  to 
support  DOT&E  requests  in  the  development  of  the  report.  DON 
acquisition  and  test  agencies  may  be  tasked  by  OPNAV  (N842)  to 
assist  in  this  effort.] 

4.11.5  Foreign  Comparative  Test  Notification  and  Report  to 
Congress* 

[from  SNI  5000. 2E,  4.11.5:  The  DUSD  (AS&C)  shall  notify 
Congress  a  minimum  of  30  days  prior  to  the  commitment  of  funds 
for  initiation  of  new  foreign  comparative  test  evaluations.  See 
reference  (a) ,  enclosure  6,  for  implementation  requirements  for 
DON  ACAT  programs  involved  in  foreign  comparative  testing. 

*Not  applicable  to  ACAT  I A  programs .] 
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Annex  4 -A 

Index  of  Test  &  Evaluation  Strategy  (TES) /Test  &  Evaluation 
Master  Plan  (TEMP)  Signature  Page  Formats 

TES/TEMP  Cover  Page  Format  for  ACAT  I/IA  and  all  programs  on  OSD 
DOT&E  Oversight  List 

TES/TEMP  Cover  Page  Format  for  ACAT  II  programs 

TES/TEMP  Cover  Page  Format  for  ACAT  III  programs 

TES/TEMP  Cover  Page  Format  for  ACAT  IV  programs 

TEMP  Cover  Page  Format  for  Software  Qualification  Testing 
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TES/TEMP  Cover  Pages 

TES/TEMP  Cover  Page  Format  for  ACAT  I/IA  Programs 

[and  other  OSD  T&E  oversight  programs] 

TEMP  NO.  [Insert  TEIN]  REV.  _  [AS  APPLICABLE] 

[PROGRAM  TITLE] 

Acquisition  Category  (ACAT)  _ 

Program  Element  No.  _ 

Project  No.  _ 


SUBMITTED  BY: 


PROGRAM  MANAGER  DATE 


CONCURRENCE : 


SYSCOM  COMMANDER/ PEO/DRPM  DATE 


COMOPTEVFOR/DIR,  MCOTEA  DATE 


PROGRAM/ RE SOURCE  SPONSOR  (Flag)  DATE 


APPROVED  FOR  NAVY  or  MARINE  CORPS: 


CNO  (N84) (Navy  Sponsored)  DATE 

ACMC  (Marine  Corps  Sponsored) 


ASN (RD&A) 


DATE 


APPROVED: 


DASD  DT&E  DATE 


DOT&E 


DATE 


Distribution  statement  per  reference  (d) ,  Chapter  8,  Exhibit  8A. 
CLASSIFIED  BY  (see  reference  (d)  ,  Chapter  6)  : 

REASON  FOR: _ 

DECLASSIFY  ON: 
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TES/TEMP  Cover  Page  Format  for  ACAT  II  Programs 

TEMP  NO.  [Insert  TEIN]  REV.  _  [AS  APPLICABLE] 

[PROGRAM  TITLE] 

Acquisition  Category  (ACAT)  II 

Program  Element  No.  _ 

Project  No.  _ 


SUBMITTED  BY: 

PROGRAM  MANAGER 

DATE 

CONCURRENCE : 

SYSCOM  COMMANDER/ PEO/DRPM 

DATE 

COMOPTEVFOR/ DIR,  MCOTEA 

DATE 

PROGRAM/ RE SOURCE  SPONSOR  (Flag) 

DATE 

APPROVED  FOR  NAVY 

or  MARINE  CORPS: 

CNO  (N84) (Navy  Sponsored) 

ACMC  (Marine  Corps  Sponsored) 

DATE 

ASN (RD&A) 

DATE 

Distribution  statement  per  reference  (d) ,  Chapter  8,  Exhibit  8A. 
CLASSIFIED  BY  (see  reference  (d)  ,  Chapter  6)  : 

REASON  FOR: _ 

DECLASSIFY  ON: 
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TES/TEMP  Cover  Page  Format  for  ACAT  III  Programs 

TEMP  NO.  [Insert  TEIN]  REV.  _  [AS  APPLICABLE] 

[PROGRAM  TITLE] 

Acquisition  Category  (ACAT)  III 

Program  Element  No.  _ 

Project  No.  _ 


SUBMITTED  BY: 

PROGRAM  MANAGER 

DATE 

CONCURRENCE : 

SYSCOM  COMMANDER/ PEO/DRPM  DATE 

(if  ASN (RD&A)  retains  MDA,  if  not,  delete  signature  line,  or 
designate  a  deputy  or  assistant  for  (title)  to  concur) 

COMOPTEVFOR/ DIR,  MCOTEA 

DATE 

PROGRAM  SPONSOR/CMC  (DC,  CD&I) (Flag) 

DATE 

APPROVED  FOR  NAVY  or  MARINE 

CORPS: 

CNO  (N84),  or  designee  (Navy  Sponsored) 

ACMC,  or  designee  (Marine  Corps  Sponsored) 

DATE 

MILESTONE  DECISION  AUTHORITY 

DATE 

Distribution  statement  per  reference  (d) ,  Chapter  8, 
CLASSIFIED  BY  (see  reference  (d)  ,  Chapter  6)  : 

Exhibit  8A. 

REASON  FOR: 

DECLASSIFY  ON: 
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TES/TEMP  Cover  Page  Format  for  ACAT  IV  Programs 

TEMP  NO.  [Insert  TEIN]  REV.  _  [AS  APPLICABLE] 

[PROGRAM  TITLE] 

Acquisition  Category  (ACAT)  IV 

Program  Element  No.  _ 

Project  No.  _ 


SUBMITTED  BY: 

PROGRAM  MANAGER 

DATE 

CONCURRENCE : 

COMOPTEVFOR/ DIR,  MCOTEA 
[for  ACAT  IVT  only] 

DATE 

APPROVED  FOR  NAVY  or  MARINE 

CORPS: 

CNO  (N84),  or  designee  (Navy  Sponsored) 
ACMC,  or  designee  (Marine  Corps  Sponsored) 
[for  ACAT  IVT  only] 

DATE 

MILESTONE  DECISION  AUTHORITY 

DATE 

Distribution  statement  per  reference  (d) ,  Chapter  8,  Exhibit  8A. 
CLASSIFIED  BY  (see  reference  (d)  ,  Chapter  6)  : 

REASON  FOR: _ 

DECLASSIFY  ON:  ""  "  "  " 
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TEMP  Cover  Page  Format  for 
Software  Qualification  Testing  Programs 

TEMP  NO.  [Insert  TEIN]  REV.  _  [AS  APPLICABLE] 

SOFTWARE  QUALIFICATION  TESTING  FOR 
[PROGRAM  TITLE] 

Program  Element  No.  _ 

Project  No.  _ 


SUBMITTED  BY: 

PROGRAM  MANAGER 

DATE 

CONCURRENCE : 

COMOPTEVFOR/ DIR,  MCOTEA 

DATE 

CNO  (N8  4 ) / CMC  (DC,  CD&I) 

DATE 

APPROVED: 

SYSCOM  COMMANDER/ PEO/DRPM 

DATE 

Distribution  statement  per  reference  (d) ,  Chapter  8,  Exhibit  8A. 
CLASSIFIED  BY  (see  reference  (d)  ,  Chapter  6)  : 

REASON  FOR: _ 

DECLASSIFY  ON: 
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Annex  4-B 


Fleet  RDT&E  Support  Request 

Request  for:  Quarter  FY :  Date  of  Request: 

Classification: 

TEIN:  _ 

Title:  _ 

Code:  (your  office  code) 

Type:  (DT&E/OT&E)  Phase: 

TEMP  Signature  Date:  _  ( DD-MMM-YY ) 

Fleet:  (PAC/LANT) _ 

Start  Date:  _  ( DD-MMM-YY )  End  Date:  _  ( DD-MMM-YY ) 

Recommended  Priority:  (1,2,3;  DON  GB,  para  4. 4. 6. 1.2) 

Purpose  of  this  phase  of  testing: _ 


Support  required:  (use  additional  paragraphs  if  additional  units  are  needed) 

A.  1.  Unit  Type  and  Number  Requested: 

Special  Equipment  to  be  installed: 

2.  Unit's  Scheduling  Authority: _ 

3.  Test  Location  (OPAREA) : 

4.  Level  of  Support: 

(not-to-interfere,  concurrent,  dedicated;  DON  GB,  para  4.4.6) 


a . 

Preferred  Dates  Start: 

( DD-MMM-YY )  End: 

(DD-MMM-YY) 

Start  No  Later  Than: 

( DD-MMM-YY ) 

Complete  No  Later  Than: 

(DD-MMM-YY) 

b . 

Number  of  Days  on  Station: 

Hours/Day: 

c . 

For  Aircraft:  A/C  Sorties: 

Hrs/ Sortie : 

,  and 

d . 

Sorties/Day: 

Minimum  Times  between  Sorties/Test  Periods: 

Remarks:  (See  Notes) 

B.  1.  Unit  Type  and  Number  Requested: 

Special  Equipment  to  be  installed: 

2.  Unit's  Scheduling  Authority: _ 

3.  Test  Location  (OPAREA) : 

4.  Level  of  Support: _ 

(not-to-interfere,  concurrent,  dedicated;  DON  GB,  para  4.4.6) 

5.  a.  Preferred  Dates  Start:  _  ( DD-MMM-YY )  End:  _  ( DD-MMM-YY ) 

Start  No  Later  Then:  _  (DD-MMM-YY) 

Complete  No  Later  Then:  _  ( DD-MMM-YY ) 

b.  Number  of  Days  on  Station:  Hours/Day: 

c.  For  Aircraft:  A/C  Sorties:  Hrs/Sortie: 

Sorties /Day: _ 

d.  Minimum  Times  between  Sorties/Test  Periods: 

6.  Remarks:  (See  Notes) _ 
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C.  1.  Unit  Type  and  Number  Requested: _ 

Special  Equipment  to  be  installed: 

2.  Unit's  Scheduling  Authority: _ 

3.  Test  Location  (OPAREA) : 

4.  Level  of  Support: _ 

(not-to-interfere,  concurrent,  dedicated;  DON  GB,  para  4.4.6) 

5.  a.  Preferred  Dates  Start:  _  (DD-MMM-YY)  End:  _  (DD-MMM-YY) 

Start  No  Later  Than:  _  ( DD-MMM-YY ) 

Complete  No  Later  Than:  _  ( DD-MMM-YY ) 

b.  Number  of  Days  on  Station:  Hours/Day: 

c.  For  Aircraft:  A/C  Sorties:  Hrs/Sortie:  ,  and 

Sorties /Day: _ 

d.  Minimum  Times  between  Sorties/Test  Periods: 

6.  Remarks:  (See  Notes) _ 


(Name;  Command;  email;  Voice  and  Fax  Phone  Numbers,  DSN  and  Commercial) 
POC: 

OTD : 

DT&E 
Coord : 

OTC : 

Program  Sponsor: 


NOTES : 

1.  Requests  should  be  as  general  as  possible  to  allow  the  schedulers 
flexibility . 

2.  Include  a  list  of  ships  that  have  the  correct  equipment  configuration 
installed  to  support  the  tests. 

3.  Designate  unique  fleet  personnel  support  requirements  (e.g.:  SEAL  Teams, 
ULQ13  Van/Crew) . 

4.  Service  request  remarks:  State  time  required  to  install  and  remove 
equipment  and  by  whom.  Address  the  following  questions: 

a.  Can  it  be  installed  pierside  (drydock/SRA/ROH) ? 

b.  Has  equipment  installation  been  approved?  By  whom? 

c.  Will  installation  affect  unit  operation  or  other  equipment 
onboard? 

d.  Is  any  crew  training  required? 

e.  How  many  riders  are  required  to  embark  (keep  to  a  minimum)? 

f.  If  more  than  one  unit  is  required,  state  which  units  must  work 
together  and  the  minimum  concurrent  time. 

5.  Address  impact  on  program  if  services  are  not  filled  such  as: 

a.  Loss  of  programmed  monies  (specify  amount) . 

b.  Increased  cost  due  to  delay  (specify  amount) . 

c.  Impact  on  related  joint  programs  or  operations. 

d.  Congressional  and/or  OSD  interest  or  direction. 

e.  Unique  factors: 

(1)  Deployment  schedule  of  test  asset. 

(2)  Overhaul  schedule. 

(3)  "One-of-a-kind"  underway  events  required  for  testing. 

f.  Delay  in  projected  production  and  cost  to  Navy. 
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Annex  4-C 


Test  and  Evaluation  Identification  Number  Request  Format 


3960 

Ser 

(DATE) 


From:  (Program  Office) 

To:  Chief  of  Naval  Operations  (N842) 

Via:  (Sponsor) 

Sub j :  REQUEST  FOR  TEST  AND  EVALUATION  IDENTIFICATION  NUMBER 
(TEIN)  ASSIGNMENT  FOR  (PROGRAM  NAME) 

Ref:  (a)  SECNAVINST  5000. 2E 

(b)  Initial  Capabilities  Document  for  (Program  Name)  of 
(Approved  Date) 

1.  Per  reference  (a),  request  a  Test  and  Evaluation 
Identification  Number  (TEIN)  be  assigned  to  the  (Program  Name) , 
(Program  Element  Number;  Project  Number) . 

(Add  2-3  sentences  describing  purpose  of  program)  This  ACAT 
(ACAT  level)  program  is  being  developed  to  meet  the  requirements 
of  reference  (b) . 

2.  Points  of  contact  are: 

Responsibility  Name  Code  Telephone 

Program  Manager  (Program  Manager) 

Requirements  (OPNAV  Sponsor) 

Officer 

T&E  Coordinator  (OPNAV  (N842)  point  of  contact) 

3.  Milestone  Status:  (indicate  dates  milestones  were  achieved 
and  planned  dates  for  future  milestones) 


(Program  Manager  Signature) 


Copy  to: 

COMOPTEVFOR  (01B6) 

(Additional  Office  codes  if  necessary) 


4-85 


Enclosure  (1) 


SECNAV  M-5000 . 2 
May  2012 


Annex  4-D 

Notional  Schedule  of  Test  Phases  in  the  Acquisition  Model 


User  Needs 


Technology  Opportunities  &  Resources 


The  Materiel  Development  Decision  precedes 
entry  into  any  phase  of  the  acquisition 
management  system 

Entrance  criteria  met  before  entering  phase 

Evolutionary  Acquisition  or  Single  Step  to 
Full  Capability 


A  A 


(Program 

Initiation) 


A 


IOC 


FOC 


Materiel 

Solution 

Analysis 

Technology 

Development 

Engineering  and 
Manufacturing 
Development 

Production  & 
Deployment 

Operations  & 
Support 

L  Materiel 
>  Development 
/  Decision 

/\POBt-  /\P08t- 
V*  PDR  A\/CDR  A 

LRIP/IOT&E  A  Decision 

V  Rev  ew 

^Pre-Systems  Acquisition/^ 


Systems  Acquisition 


/\  Sustainment 


Decision  Point  /\=  Milestone  Review  \  >=  Decision  Point  if  PDR  is  not  conducted  before  Milestone  B 


Developmental  Tests 


Operational  Tests 

Integrated  Test  Plans  may  use  IT  in 
similar  naming  convention  by  phase. 
IT  should  only  be  used  when  DT  and 
OT  test  objectives  have  coordinated 
test  plans. 


Testing  multiple  increments. 

Use  Arabic  numerals  immediately 
following  acquisition  phase  letter  then 
dash  for  test  events  within  the  phase 


EOA 

Early 

Operational 

Assessments 


OA 

Operational 
Assessments 
Combined  DT/OT 


I  DT-A-1,2,  etc  c  DT-B-1,2,  etc  f  1 

AI 

y) 

DT-D-1,  2,  etc 

TECHE\ 
(DT-C  - 

j  OT-A-1,2,  etc 

OT-B-1,  2,  etc 

OT-C-x 

FOT&E 

iot&e 

(OT-C  -  y) 


♦ 


o 


DT-B1-1,2,  elc 

OT-Bli-1, 2,  etc 


OT-D-x 

A 

FRP 

DT-C1-1,  2,  etc 
OT-Cl-x 

<2  /c 


l  DRR 

t>T-B2-l,2,  etc 


o 

FRP 


DT-C2-1, 2,  etc 
OT-B2-1, 2,  etc  OT-C2-X 


IOT&E 

Initial  Operational 
Test  &  Evaluation 
(OPEVAL) 
Combined  DT/OT 


FOT&E 
Follow-on 
Operational  Test, 
VCD 
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Annex  4-E 


Certification  of  Readiness  for  OT  Message  Content 


The  message  certifying  a  system's  readiness  for  OT&E 
should  contain  the  following  information: 

1 .  Name  of  the  system 

2 .  OT- [phase ] 

3.  TEMP  [number] 

4 .  TEMP  approval  date 

5.  For  software  testing,  identify  the  specific  release 
to  be  tested. 

6.  Waivers  (identify  criteria  in  SECNAVINST  5000. 2E  to 
be  waived,  if  any;  if  none,  state  "none")  .  (SECNAVINST  5000. 2E 
should  be  Ref  A  of  the  certification  message) 

7.  State  projected  limitations  that  waived  criteria  will 
place  on  upcoming  operational  testing. 

8.  Deferrals  (identify  deferrals  from  a  testing 
requirement  directed  in  the  TEMP;  if  none,  state  "none".) .  (The 
TEMP  should  be  Ref  B  of  the  certification  message) 

9.  State  projected  limitations  that  waived  TEMP 
requirement  will  place  on  upcoming  operational  testing. 

10.  State  potential  waiver  impact  on  fleet  use. 

11.  State  when  waived  requirement  will  be  available  for 
subsequent  operational  testing. 

12.  Additional  remarks. 

A  format  for  the  Navy  certification  of  readiness  for 
Operational  Test  and  Evaluation  message  is  provided  on  the 
following  page. 


4-87 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


Navy  Developing  Activity  Certification  Message  Format 


FM  [Developing  Activity  (DA) ] 

TO  CNO  WASHINGTON  DC//N84// 

INFO  COMO PTE VFOR  NORFOLK  VA//00// 

SECDEF  WASHINGTON  DC/ /DOT&E/DT&E// ( if  on  OSD  oversight  list) 

[info  other  commands  as  appropriate] 

[Classification] //N05000// 

MSGID/GENAMDIN/ [DA] / (Code) // 

SUB J /  [Program  Name]  CERTIFICATION  OF  READINESS  FOR  OPERATIONAL  TEST  AND 
EVALUATION  (OT-XXX) ,  CNO  PROJECT  xxxx// 

REF/A/DOC/SECNAVINST  5000 . 2E/date// 

REF/B/DOC/TEMP  xxxx/ (date) // 

[Other  references  as  appropriate] 

NARR/REF  A  IS  A  SECNAVINST  FOR  IMPLEMENTATION  OF  OPERATION  OF  THE  DEFENSE 
ACQUISITION  SYSTEM  AND  THE  JOINT  CAPABILITIES  INTEGRATION  AND  DEVELOPMENT 
SYSTEM.  REF  B  IS  THE  [Program  Name]  TEST  AND  EVALUATION  MASTER  PLAN  NO.  xxxx 
APPROVED  ON  [date].// 

POC/ [Name] / [Program  Office  Code] /-/-/TEL : COM (xxx) xxx-xxxx/TEL : DSN  xxx-xxxx// 

RMKS/1.  I AW  REF  A,  THIS  MESSAGE  CERTIFIES  THAT  THE  [Program  Name],  (for 
software  testing  identify  the  specific  release  to  be  tested  during  OT&E)  IS 
READY  FOR  OPERATIONAL  TEST  (OT-xxx)  AS  OUTLINED  IN  REF  B. 

2.  WAIVERS  TO  THE  CRITERIA  OF  REF  A  ARE  REQUESTED  FOR: 

A:  [Identify  Ref  A,  chapter  4,  para  4.6.1,  criteria  to  be  waived,  if 

any;  if  none,  so  state. 

(1)  (Limitation  that  waived  criteria  will  place  on  upcoming 
operational  testing.] 

[Repeat  above  format  for  each  criteria  requested  for  waiver.] 

3.  DEFERRALS  TO  TESTING  SYSTEM  CAPABILITIES/REQUIREMENTS  OF  REF  B: 

A:  [State  requested  deviation  from  a  testing  requirement  directed  in 

Ref  B  TEMP.  Cite  specific  critical  operational  issues  (COIs)  in 
Ref  B;  if  none,  so  state.] 

(1)  [Limitations  that  deferred  TEMP  requirement  will  place  on 

upcoming  operational  testing.] 

(2)  [Potential  impacts  on  fleet  use.] 

(3)  [State  when  deferred  requirement  will  be  available  for 

subsequent  operational  testing.] 

[Repeat  above  format  for  each  TEMP  requirement  requested  for  deferral . ] 

4.  [Additional  remarks  as  appropriate.] 

A:  [State  any  other  issues  that  may  impact  the  test,  such  as  limited 

resources  or  timing  constraints  for  testing.] 


BT 
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Chapter  5 

Resource  Estimation 


References : 


(a)  SECNAVINST  5223.2 

(b)  POD  Instruction  5000.02  of  8  Dec  2008 

(c)  USD(P&R)  Memorandum,  Interim  Policy  and 
Procedures  for  Strategic  Manpower  Planning  and 
Development  of  Manpower  Estimates,  of  10  Dec 
2003 


5.1  Resource  Estimates 


5.1.1  Life-Cycle  Cost  Estimates/Service  Cost  Position 

[ from  SNI  5000. 2E,  basic  instruction,  para  7.t.:  The 
Deputy  Assistant  Secretary  of  the  Navy  (Cost  and  Economics) 

(DASN (C&E) )  is  dual-hatted  as  the  Director  of  the  Naval  Center 
for  Cost  Analysis  (NCCA) .  DASN (C&E)  serves  as  the  principal 
advisor  to  DON  leadership  on  issues  of  cost  analysis  and  reports 
directly  to  the  Assistant  Secretary  of  the  Navy  (Financial 
Management  and  Comptroller)  (ASN (FM&C) ) .  Reference  (a)  fully 
defines  NCCA  responsibilities,  which  include: 

a.  Preparing  life-cycle  independent  cost  estimates  (ICEs) 
for  major  defense  acquisition  programs  (MDAPs)  designated 
acquisition  category  (ACAT)  IC  at  milestones  B  and  C  and  full- 
rate  production  decision  review  (FRP  DR)  per  section  2434  of 
title  10,  U.S.C.,  and  developing  component  cost  analyses  of  ACAT 
I AC  programs  at  milestone  A,  and  milestone  B,  and  full  deployment 
decision  review.  NCCA  also  conducts  component  cost  analyses  for 
joint  ACAT  I AM  programs  for  which  DON  is  the  lead. 

b.  Assessing  SYSCOM-generated  program  life-cycle  cost 
estimates  for  all  ACAT  I  programs  and  selected  ACAT  II  programs , 

{and  independently  assessing  risks  and  uncertainties  of  these 
programs  (added  in  this  guidebook  for  clarification)},  as 

directed  by  ASN (FM&C)  . 

c.  Collaborating  with  SYSCOM  cost  organizations  to 
determine  common  DON  Service  Cost  Positions  (SCPs)  on  all  ACAT  I 
and  IA  programs ,  and  selected  ACAT  II  programs ,  and  approving  a 
common  DON  Service  Cost  Position .] 

DON' s  Cost  Estimating  Guide  (CEG) ,  available  under 
references  at  www.NCCA.Navy.mil,  is  a  compendium  of  best 
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practices  that  should  generally  underpin  LCCEs  of  weapon  system 
and  automated  information  system  acquisition  programs.  The  basic 
precepts,  processes,  and  procedures  of  the  Guide  apply  equally  to 
the  development  of  Program  LCCEs,  ICEs,  and  SCPs . 

The  GEG  strives  to  improve  and  standardize  processes  and 
procedures  while  recognizing  the  fluidity  inherent  in  the  field 
of  defense  cost  analysis.  Practices  and  procedures  necessarily 
vary  between  cost  analysis  organizations,  at  least  to  some 
degree,  according  to  mission  requirements,  workload,  staffing, 
and  special  circumstances.  The  CEG,  then,  is  not  strictly 
prescriptive;  that  is,  organizations  are  free,  as  exigencies 
dictate,  to  vary  from  its  tenets. 

Nevertheless,  the  CEG  represents  a  consensus  of  best 
practices  useful  to  cost  analysis  practitioners,  their 
organizations,  and  to  other  stakeholders  involved  in  producing 
and  using  our  cost  estimates.  The  order  and  the  emphasis  of 
material  covered  in  the  CEG  attempt  to  follow  state-of-the-art 
themes  and  concepts  in  the  profession,  such  as  the  need  to  begin 
risk  and  uncertainty  analysis  early  on,  the  need  to  question  the 
accuracy  of  baseline  parameters  and  to  obtain  buy  in  on  the 
baseline  from  all  stakeholders,  and  the  need  to  independently 
verify  and  validate  the  cost  estimate  prior  to  its  delivery. 

The  ASN (FM&C)  and  ASN (RD&A)  joint  memorandum.  Department 
of  the  Navy  Service  Cost  Positions,  of  7  Jan  2010,  available 
under  references  at  www . NCCA . Navy .mil,  provides  the  policy  and 
process  for  establishing  and  approving  a  SCP  for  each  Department 
of  the  Navy  ACAT  ID,  IC,  IA,  and  selected  ACAT  II  programs.  This 
process  also  applies  to  the  establishment  of  an  SCP  for  the  naval 
component  of  joint  ACAT  I  programs  and  other  programs  wherein  the 
DON  is  expected  to  provide  a  Component-level  cost  position.  SCPs 
are  established  to  serve  as  the  DON  Component-level  cost  position 
to  comply  with  the  requirements  of  the  Office  of  the  Secretary  of 
Defense . 


DASN  (C&E)  is  the  signature  authority  for  all  DON  SCPs. 
Systems  Command  Cost  Directors  co-sign  SCPs  for  ACAT  ID  programs. 
The  SCP  process  is  intended  to  consider  cost  inputs  from  all 
contributors  to  the  cost  estimating  process. 

The  SCP  is  the  DON  official  life-cycle  cost  estimate  of 
all  resources  and  associated  cost  elements  required  to  develop, 
produce,  deploy,  sustain,  and  dispose  of  a  particular  system.  The 
SCP  encompasses  all  past  (or  sunk) ,  present,  and  future  costs  of 
the  program,  regardless  of  funding  source. 

5.1.2  Cost  Analysis  Requirements  Description  (CARD) 
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A  sound  cost  estimate  is  based  on  a  well-defined  program. 
The  CARD  is  used  to  formally  describe  the  acquisition  program 
(and  the  system  itself) ,  as  well  as  summarize  life-cycle  support 
and  sustainment  planning,  for  purposes  of  preparing  the  program 
office  cost  estimate  for  all  ACAT  programs,  the  DoD  Component 
(DON)  Service  Cost  Position  (SCP)  for  ACAT  I,  IA,  and  selected 
ACAT  II  programs,  the  Office  of  the  Secretary  of  Defense  (OSD) 
Cost  Analysis  and  Program  Evaluation  (CAPE)  ICE  for  ACAT  ID  and 
IAM  programs,  and  the  NCCA  ICE  for  ACAT  IC  programs.  A  CARD  is 
required  in  the  DON  whenever  a  weapon-system  cost  estimate  is 
required;  that  is,  for  all  ACAT  programs,  at  all  milestones.  In 
addition,  for  major  automated  information  system  programs,  the 
CARD  is  prepared  to  support  major  milestones  (Milestones  A  and  B, 
and  Full  Deployment  Decision  Review)  and  whenever  an  Economic 
Analysis  is  required.  The  CARD  is  prepared  by  the  program 
manager  and  approved  by  the  Department  of  Defense  (DoD)  Component 
(DON)  SYSCOM  Cost  Director.  For  joint  programs,  the  CARD 
includes  the  common  program  agreed  to  by  all  participating  DoD 
Components  as  well  as  all  unique  program  requirements  of  the 
participating  DoD  Components.  DoD  5000. 4-M,  DoD  Cost  Analysis 
Guidance  and  Procedures ,  of  11  Dec  1992,  and  reference  (a) 
provide  further  guidance  for  the  preparation  of  the  CARD. 

5.1.3  Manpower  Estimates 

[ from  SNI  5000. 2E,  5.1.3:  Manpower  estimates  are  required 
by  statute  for  ACAT  I  programs.  Manpower  estimates  shall  also  be 
developed  for  other  ACAT  programs  that  are  manpower  significant 
at  the  request  of  the  Component  manpower  authority  per  reference 
(c) .  CNO  (Nl)  and  CMC  (Deputy  Commandant ,  Combat  Development  and 
Integration  (DC,  CD&I) )  are  the  designated  Navy  and  Marine  Corps 
Component  manpower  authorities ,  respectively .  For  ACAT  ID 
programs,  CNO  (Nl) /CMC  (DC,  CD&I)  shall  forward  approved  manpower 
estimates  to  the  office  of  the  Under  Secretary  of  Defense 
(Personnel  and  Readiness) .  Additional  policy  and  guidance  on  the 
development  of  manpower  estimates  (including  required  submission 
timeline ,  content/ format ,  and  use  of  manpower  estimates)  is 
provided  in  reference  (c)  .  ] 

Manpower  Estimates  (MEs)  are  one  of  the  key  documents  of 
human  systems  integration.  MEs  are  a  source  for  out-year 
projections  of  military  and  civilian  manpower  and  contract 
support  required  for  the  acquisition  and  upgrade  of  weapon, 
support  and  automated  information  systems.  MEs  are  required  by 
section  2434  of  title  10,  U.S.C.  Development  of  the  manpower 
estimate  is  the  responsibility  of  the  resource  sponsor.  MEs  may 
be  requested  by  CNO  (N1)/CMC  (DC,  CD&I)  for  other  selected 
programs.  The  initial  ME  is  required  at  MS  B  with  an  update  at 
MS  C  and  FRP  DR.  MEs  should  include  a  target  audience  description 
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(TAD)  that  provides  information  about  the  personnel  that  will 
use,  operate,  maintain,  train  and  repair  a  system.  The  TAD  may 
consist  of  military  personnel,  civilians  and/or  contractors,  or  a 
mix  thereof.  If  it  is  a  joint  service  system,  members  of  the 
other  branches  of  service  should  also  be  identified  and  included 
as  a  part  of  the  TAD.  The  TAD  provides  a  description  of  the 
quantity,  qualifications,  and  characteristics  of  the  personnel 
who  will  operate,  maintain  and  support  the  system.  The  TAD  also 
is  the  baseline  for  the  Traininq  System  Plan  and  Affordability 
Assessment,  as  well  as  providinq  a  baseline  for  desiqn  trade¬ 
offs. 


5. 1.3.1  Manpower  Considerations 

The  PM  should  determine  and  document  manpower  by  rate  and 
ratinq  for  both  peacetime  and  wartime  requirements.  The  PM 
should  further  identify  specific  vital  objectives,  and  establish 
manpower  authorization  minimums  necessary  to  achieve  these 
objectives.  CNO  (Nl)  assistance  may  be  used  in  developinq 
manpower  life-cycle  cost  estimates  for  ACAT  II,  III,  and  IV 
proqrams,  if  requested  by  the  milestone  decision  authority  (MDA) 
or  the  resource  sponsor. 

5 . 2  Program  Funding 

5 . 3  Contract  Management  Reports 

5.3.1  Cost  and  Software  Data  Reporting  (CSDR)  for  Hardware 
and  Software  —  (DID  DI-FNCL-81565B/81566B/81567B)  and  Software 
Resources  Data  Report  (SRDR)  —  (DID  DI-MGMT-81739/81740) 

5.3.2  Contract  Performance  Report  (CPR)  --  (DID  DI-MGMT- 
81466) 

5.3.3  Integrated  Master  Schedule  (IMS)  --  (DID  DI-MGMT-81650) 

5.3.4  Contract  Funds  Status  Report  (CFSR)  -  (DID  DI-MGMT- 
81468) 


5 . 4  Analysis  of  Alternatives  (AoA) 

[ from  SNI  5000.2E,  5.4:  The  Gate  1  and  Gate  2  processes  of 
chapter  1,  paragraphs  1.11.4.1.1.1  (Gate  1)  and  1.11.4.1.1.2 
(Gate  2)  amplify  the  AoA  processes  defined  below  and  the  guidance 
in  SECNAV  M-5000.2  DON  Acquisition  and  Capabilities  Guidebook , 
paragraph  5.4.] 

After  an  Initial  Capabilities  Document  (ICD)  is  validated. 
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a  Materiel  Development  Decision  (MDD)  is  made  to  address  some  or 
all  of  the  capability  gaps  identified.  The  incorporation  of 
concepts  discussed  in  the  ICD,  as  well  as  those  developed  from 
related  System  of  Systems  (SoS)  or  Family  of  Systems  (FoS) , 
require  additional  analysis  and  refinement  to  ensure  any 
potential  materiel  solutions  achieve  sufficient  mission 
capability  and  economic  benefit  is  achieved  from  any  potential 
materiel  solutions. 


MSA 


Figure  5-1.  AoA  and  the  JCIDS/Acquisition  Process 

All  DON  ACAT-level  programs  require  the  completion  of  an 
AoA  prior  to  program  initiation.  Typically,  this  is  in  direct 
support  of  a  Milestone  A  decision,  as  shown  above,  but  in  certain 
circumstances  the  MDA  can  direct  additional  reviews  of 
alternatives  leading  to  a  Milestone  B  or  C  decision.  AoAs  must 
therefore  be  tailored  to  the  scope,  increment,  phase,  and 
potential  ACAT-level  of  the  individual  programs  they  support. 

Per  reference  (b) ,  all  ACAT  ID  and  IAM  programs  will 
receive  AoA  Study  Guidance  prepared  by  the  Office  of  the 
Secretary  of  Defense  (OSD)  Director,  Cost  Assessment  and  Program 
Evaluation  (CAPE) ,  with  input  as  appropriate  from  the  Services, 
as  part  of  the  approval  process  at  MDD.  All  DON  ACAT  ID  and  IAM 
programs  must  incorporate  the  AoA  Study  Guidance  into  their  AoA 
Study  Plan. 

All  ACAT  IC,  IAC,  II,  III,  and  IV  programs  require  an  AoA 
Study  Plan  prepared  by  the  Program  or  Resource  Sponsor  and  the 
Independent  Activity  Analysis  Director  and  jointly  approved  by 
the  MDA  and  CNO  (N81)  or  CMC  (DC,  CD&I) . 

For  joint  ACAT-level  programs  in  which  DON  has  been 
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designated  the  Lead  Service,  AoA  procedures  should  be  tailored  to 
include  other  Service  representatives  and  approval  authorities. 

In  addition,  consideration  should  be  given  to  the  potential  for 
international  collaboration  and  acquisition  options  when 
appropriate . 

Once  completed,  the  AoA  aids  decision-making  in 
establishing  initial  system  performance  thresholds  and 
objectives,  identifies  cost  and  performance  trade-offs,  and 
highlights  the  analytical  underpinnings  for  a  multitude  of 
program  decisions.  In  general,  the  AoA  provides  a  structured 
review  and  documentation  of  the  life-cycle  costs  and  operational 
effectiveness  of  the  alternatives,  assumptions,  and  conclusions 
supporting  the  rationale  for  proceeding  to  a  materiel  solution. 

5.4.1  Weapon  System  AoA  (and  IT  AoA  where  noted) 

a.  All  DON  weapon  systems,  regardless  of  ACAT  level,  must 
complete  an  AoA  prior  to  program  initiation.  Per  reference  (b) , 
program  initiation  normally  occurs  at  Milestone  B,  but  may  occur 
at  other  milestones/decision  points  depending  upon  technology 
maturity  and  risk.  At  program  initiation,  a  program  must  be 
fully  funded  across  the  Future  Years  Defense  Program  (FYDP)  as  a 
result  of  the  Program  Objectives  Memorandum  (POM) /budget  process. 
That  is,  the  program  must  have  an  approved  resource  stream  across 
a  typical  defense  program  cycle  (e.g..  Fiscal  Year  (FY)  2006- 
2011).  Materiel  Solution  Analysis  and  Technology  Development 
(TD)  phases  are  typically  not  fully-funded  and  thus  do  not 
constitute  program  initiation  of  a  new  acquisition  program  in  the 
sense  of  reference  (b) . 

b.  Reference  (b) ,  enclosure  4,  Table  3  directs  multiple 
AoA  reviews  for  all  ACAT  I  programs  as  follows:  Milestone  A, 
Milestone  B  (update  as  necessary) ,  and  Milestone  C  (update  as 
necessary) .  The  final  report  should  discuss  steps  taken  to 
ensure  compliance  with  the  Clinger-Cohen  Act  for  weapon  systems 
that  are  National  Security  Systems. 

c.  AoAs  differ  at  each  milestone,  if  prepared. 

(1)  At  Milestone  A,  the  analysis  focuses  on  broad 
tradeoffs  available  between  a  large  range  of  different  concepts. 
The  analysis  normally  presents  a  "Go/No  Go"  recommendation.  It 
demonstrates  why  a  new  system  is  better  than  upgrading/modifying 
an  existing  system.  Cost  estimates  may  be  only  a  rough  order  of 
magnitude  but,  nevertheless,  an  estimate  is  required.  A 
Milestone  A  AoA  helps  the  MDA  choose  a  preferred  system  concept 
and  decide  whether  the  cost  and  performance  of  the  concept 
warrants  initiating  an  acquisition  program.  These  types  of 
analyses  also  illuminate  the  concept's  cost  and  performance 
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drivers  and  key  tradeoff  opportunities;  and  they  provide  the 
basis  for  the  establishment  of  operational  performance  thresholds 
and  objectives  used  in  the  Capability  Development  Document  (CDD) , 
Acquisition  Program  Baseline  (APB) ,  and  Test  and  Evaluation 
Master  Plan  (TEMP) . 

(2)  At  Milestone  B,  the  analysis  is  more  focused. 
Hardware  alternatives  present  a  narrower  range  of  choices.  The 
analysis  is  more  detailed  and  contains  more  defined  cost  data. 
Point  estimates  are  given  with  uncertainty  ranges.  Life-cycle 
costs  are  normally  presented. 

(3)  At  production/limited  deployment  approval 
(Milestone  C) ,  the  AoA,  if  required,  is  normally  an  update  of  the 
Milestone  B  document.  It  highlights  any  trade-off  or  cost 
changes.  However,  since  cost  and  performance  issues  have 
typically  been  resolved  prior  to  Milestone  C,  an  AoA  is  not  often 
required  to  support  this  milestone. 

d.  If  the  AoA  is  to  be  supplemented  by  another  Service 
developed  analysis,  the  program  or  resource  sponsor  of  the  AoA 
should  ensure  that  the  assumptions  and  methodologies  used  are 
consistent  for  both  Services. 

f.  See  annex  5-A  for  AoA  preparation  and  processing 
procedures . 

5.4.2  IT  AoA 

a.  AoAs  involving  automated  information  systems  are 
basically  the  same  as  discussed  above;  however,  they  must  be 
constructed  in  a  way  that  clearly  demonstrates  full  compliance 
with  all  requirements  discussed  in  reference  (b)  and  chapter  4 
of  this  guidebook. 

b.  The  final  report  should  discuss  steps  taken  to 
ensure  compliance  with  the  Clinger-Cohen  Act  and  Financial 
Management  Enterprise  Architectures. 

c.  Reference  (b) ,  enclosure  4,  Table  3  directs  multiple 
AoA  reviews  for  all  ACAT  IA  major  automated  information  systems 
as  follows:  Milestone  A,  Milestone  B  (update  as  necessary). 
Milestone  C  (update  as  necessary)  and  Full  Deployment  Decision 
Review  (for  AIS) . 

d.  See  annex  5-A  for  AoA  preparation  and  processing 
procedures . 

5.4.3  Navy  AoA  Environmental  Reviews 
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AoAs  should  identify  the  potential  ESOH  impact  of  each 
alternative  in  terms  of  mitigation  costs  and  the  affect  on  fleet 
readiness  over  the  life-cycle. 

5 . 5  Cost  as  an  Independent  Variable  (CAIV) 

CAIV  should  account  for  the  cost  of  Manpower,  Personnel, 
and  Training  (MPT) .  As  part  of  CAIV,  the  PM  should  explore 
options  that  maximize  use  of  technology  to  reduce  MPT 
requirements.  CAIV  planning  should  account  for  the  cost  and  risk 
of  final  disposal,  with  particular  reference  to  hazardous 
materials.  Requirements  for  product  reclamation  and  recycling 
should  be  included.  CAIV  analyses  should  consider  hazardous 
material  management,  disassembly,  disposal,  and  reuse  or  resale 
of  recovered  materials. 

5.5.1  Cost/Schedule/Performance  Tradeoffs 

For  those  programs  that  are  part  of  a  SoS  or  FoS,  cost- 
performance  tradeoffs  should  be  performed  in  the  context  of  an 
individual  system  executing  one  or  more  mission  capabilities  of 
the  SoS  or  FoS . 
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Annex  5 -A 

Weapon  System  and  IT  System  Programs 
Analysis  of  Alternatives  Development  Procedures 


1 . 1  Analysis  of  Alternatives  Overview 

While  the  use  of  analyses  to  support  programmatic 
decisions  is  not  new,  the  AoA  process  brings  formality  to  the 
Materiel  Solution  Analysis  phase  by  integrating  the  joint 
capabilities  development  and  the  pre-systems  acquisition 
processes.  In  particular,  the  AoA  process  provides  a  forum  for 
discussing  risk,  uncertainty,  and  the  relative  advantages  and 
disadvantages  of  alternatives  being  considered  to  satisfy  mission 
capabilities.  The  AoA  shows  the  sensitivity  of  each  alternative 
to  possible  changes  in  key  assumptions  (e.g.,  threat)  or 
variables  (e.g.,  performance  capabilities)  and  represents  one  way 
for  the  MDA  to  address  issues  and  questions  early  in  pre-systems 
acquisition  and  during  a  program's  life-cycle. 

Involvement  of  senior  experienced  and  empowered 
individuals  from  both  the  Chief  of  Naval  Operations 
(CNO) /Commandant  of  the  Marine  Corps  (CMC)  and  the  acquisition 
communities  plays  a  key  role  in  the  analytical  process.  Periodic 
reviews  prior  to  key  decision  points  afford  high-level  visibility 
to  potential  programs,  provides  analytical  rigor  and  flexibility 
for  development  of  the  initial  acquisition  strategy,  and  allow 
for  coordination  of  effort  between  evolutionary  increments  and 
other  defense  programs.  Review  of  in-progress  analysis  ensures 
the  analysis  addresses  the  key  issues  at  hand  and  associated  top- 
level  architectural  views,  assumptions,  and  limitations. 

1 . 2  Analysis  of  Alternatives  Focus  and  Scope 

The  AoA  supports  milestone  reviews  and  the  development  of 
follow-on  Joint  Capabilities  Integration  and  Development  System 
(JCIDS)  documentation.  Prior  to  commencement  of  any  AoA  study, 
it  is  necessary  for  programs  to  develop  and  receive  approval  of 
AoA  Study  Guidance  and  an  AoA  Study  Plan  to  support  the  Materiel 
Development  Decision.  The  AoA  Study  Plan  documents  the 
incorporation  of  DoD  and  MDA  guidance  and  allows  senior 
leadership,  in  conjunction  with  the  AoA  Executive  Steering 
Committee  (ESC) ,  to  control  the  focus  and  scope  of  the  AoA.  An 
AoA  Study  Guidance  and  an  AoA  Study  Plan  may  be  combined  for  ACAT 
IC,  IAC,  and  below  programs. 

a.  The  scope  of  analysis  should  correlate  to  the  amount 
of  resources  affected  by  the  decision,  with  ACAT  III  programs 
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receiving  less  analytical  attention  than  ACAT  I  and  II  programs. 

b.  If  the  preferred  alternative  has  already  been 
identified  by  previous  analyses  and  the  MDA  and  CNO/CMC  formally 
agree  that  all  issues  have  already  been  resolved  or  that  further 
analysis  is  unlikely  to  aid  in  the  resolution  of  outstanding 
issues,  a  new  analysis  effort  should  not  be  initiated.  (If  these 
conditions  are  met,  the  AoA  may  simply  present  the  rationale  and 
any  existing  analyses  applicable  to  program  decisions  already 
made . ) 


c.  For  smaller  programs,  the  analysis  should  be  tailored 
and  should  be  less  rigorous  than  larger  programs.  However,  in  the 
unique  situation  where  the  resolution  of  substantive  issues  would 
benefit  from  a  more  rigorous  process,  the  MDA  should  direct  the 
conduct  of  a  more  in-depth  analysis.  Designation  of  independent 
activities  to  conduct  the  AoA  for  potential  ACAT  III  and  IV 
programs  is  encouraged,  but  not  required. 

d.  AoAs  for  systems  that  are  part  of  a  SoS  or  FoS  should 
include,  within  their  scope,  discussions  on  the  interoperability 
requirements  and  concerns  under  which  these  system  interoperate. 

e.  With  few  exceptions,  technical  studies  are  beyond  the 
scope  of  an  AoA.  These  studies  are  conducted  under  the 
supervision  of  the  program  manager  who  will  then  supply  the 
results  for  incorporation  in  the  AoA. 

1 . 3  Initiation  of  the  Analysis  of  Alternatives  Process 

The  Program  Sponsor,  in  coordination  with  the  AoA  ESC, 
will  be  responsible  for  developing  the  scope  of  analysis.  At  a 
minimum,  this  scope  of  analysis  should  identify  the  independent 
activity  responsible  for  conducting  the  analysis,  alternatives  to 
be  addressed,  CNO  (N81)  approved  campaign  analysis  model (s)  to  be 
used  (when  applicable) ,  proposed  completion  date,  operational 
constraints  associated  with  the  need,  and  specific  issues  to  be 
addressed . 

For  potential  SoS  or  FoS  programs,  the  scope  of  the 
analysis  should  include  at  a  minimum  the  SoS  or  FoS  within  which 
the  program  must  interoperate.  In  addition,  the  program  or 
resource  sponsor  should  consider  potential  coalition  warfare 
operations  involving  alliance  assets. 

a.  The  scope  of  the  analysis  is  defined  in  an  AoA  Study 
Plan  (see  the  next  page  after  Table  E5T1  for  format)  which  is 
approved  by  the  individuals  shown  in  the  following  table: 
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Table  E5T1  AoA  Study  Plan  Approval  Authorities 

ACAT  ID  and  IAM 

ACAT  IC  IAC,  and  II 

ACAT  III  and  IV 

DCAPE 

(endorsed  by  ASN(RD&A),  or  designee, 

&  CNO  (N81)  or  CMC  (DC,  CD&I)) 

ASN(RD&A),  or  designee,  & 

CNO  (N81)  or  CMC  (DC,  CD&I) 

MDA  &  CNO  (N81)  or 

CMC  (DC,  CD&I) 

b.  The  OSD  Director,  Cost  Assessment  and  Program 
Evaluation  (DCAPE)  provides  the  AoA  Study  Guidance  and  approves 
the  AoA  Study  Plan  for  ACAT  ID  and  IAM  programs.  For  less  than 
ACAT  ID  and  IAM  programs,  ASN (RD&A)  or  MDA,  or  designee,  and  CNO 
(N81)  or  CMC  (DC,  CD&I)  will  jointly  approve  the  AoA  Study  Plan. 
The  AoA  Study  Plan  format  is  provided  below. 
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ANALYSIS  OF  ALTERNATIVES  (AoA)  STUDY  PLAN 


Program/Capability  Title:  [e  g.,  Strike  Directed  Infra-Red  Countermeasure  (Strike  DIRCM)] 
Proposed  ACAT:  [e  g., //] 

Milestone  Supported  by  the  AoA  (or  AoA  Update):  [e  g.,  A] 

Analysis  Director:  [ Director ’s  Name,  Employer ’s  Name  or  Agency ] 

Executive  Steering  Committee  (ESC):  [ Leadership  stakeholders  and  decision-makers; 
rank/seniority  may  vary  depending  on  anticipated  ACAT  level  of  the  program ] 

Schedule  of  AoA  Deliverables  and  near-term  milestones  [ e.g .,  dates  for  AoA  Study  Plan 
submitted  to  ESC,  AoA  Study  Plan  approved,  Interim  Program  Reviews,  Fined  Report,  Milestone 
A] 

Background 

Source  of  the  capability  gap(s)  [e.g.,  validated  Capabilities  Document,  UON/JUON] 
Capability  gap(s)  to  be  addressed 

Initial/Full  Operational  Capability  (IOC/FOC)  need  dates  and  descriptions 
Key  questions  to  be  answered 
Previous  applicable  studies/analysis 

Constraints  and  Assumptions 

Definitions  of  the  current  baseline  (existing  and  FYDP  planned)  capability 
Timeline/cost  for  completion  of  the  study 
Cost  limitations  on  the  solutions 

Expected  enabling  capabilities  for  the  alternatives,  i.e.,  kill  chain  dependencies 

Alternatives  Definition.  [Including  existing  programs  and  non-materiel  solutions.  Alternatives 
typically  consist  of  the  baseline  alternative;  modifications  to  the  baseline; 
government/commercial  off-the  shelf  (GOTS/COTS)  alternatives,  including  foreign  government 
alternatives;  and/or  new/emerging  alternatives .] 

Nonviable  Alternatives  and  rationale 
Alternatives  to  be  examined  and  description 
Operations  Concepts 
Sustainment  Concepts 

Effectiveness  Analysis 

Mission  Tasks 
Effectiveness  Methodology 
Measures  of  Effectiveness 
Measures  of  Performance 
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Scenarios  [Scenarios  will  be  based  on  OSD  Defense  Planning  Scenarios.  If  required, 
excursions  from  scenarios  will  be  approved  by  the  ESC.] 

Threats  and  Operational  Environments 

Performance  sensitivity  and/or  risk  analysis  methodology  and  considerations 

Cost  Analysis 

Applicable  guidance/directives  (e.g.,  Resource  Management  Decision  language, 
USD(Comptroller)  guidance) 

Base  year  and  inflation  indices  to  be  used 

Specific  life-cycle  phases,  cost  categories,  and/or  appropriations  to  include  in  the  study 
Manpower,  O&M,  and  life-cycle  methodology 
Additional  total  ownership  cost  consideration 

Methodology  to  examine  fully  burdened  cost  of  delivered  energy  (if  applicable) 

System  integration  requirements  to  consider 

Cost  sensitivity  and  /or  risk  analysis  methodology  and  consideration 

Cost  Effectiveness  Comparison 

Cost  Effectiveness  Methodology 
Criteria  for  Screening  Alternatives 


SUBMITTED: 

Program  Sponsor,  Code  Date  PEO/SYSCOM/DRPM  Date 

ENDORSED/APPROVED: 

CNO  (N81)  or  CMC  (DC,  CD&I)  Date  ASN(RD&A),  MDA  or  designee  Date 

DCAPE  (ACAT  ID  and  IAM)  Date 
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1 . 4  Oversight  of  the  Analysis  of  Alternatives  Process 

a.  When  the  scope  of  the  AoA  effort  warrants,  an  AoA 
Executive  Steering  Committee  (ESC)  and/or  Integrated  Product  Team 
(IPT)  consisting  of  appropriate  members  of  the  core  ACT  or 
stakeholders  organizations,  representatives  from  DASN (RDT&E) 
chief  systems  engineer  (CHSENG) ,  and  other  organizations  deemed 
appropriate  by  the  MDA,  will  be  assembled  to  assist  the  Analysis 
Director.  The  AoA  IPT  should  be  co-chaired  by  the  cognizant 
PEO/SYSCOM/DRPM,  or  cognizant  Deputy  ASN (RD&A)  if  a 
PEO/SYSCOM/DRPM  has  not  been  assigned,  and  the  Program  Sponsor. 
When  CNO/CMC  requests,  the  AoA  lead  should  be  responsible  for 
scheduling  a  formal  briefing  of  the  final  results. 

b.  The  purpose  of  the  ESC  and/or  IPT  is  to  oversee  the 
AoA,  provide  advice  and  counsel  to  the  independent  analysis 
director,  and  make  recommendations  to  ASN (RD&A)  or  the  MDA  and 
CNO/CMC.  MDAs  should  ensure  that  an  ESC  or  IPT  is  tailored  in 
scope  and  size  to  each  specific  AoA.  For  potential  programs  that 
may  be  part  of  a  SoS  or  FoS,  the  ESC  or  IPT  should  include 
representation  from  the  SoS  or  FoS  within  which  the  program  must 
be  interoperable.  The  oversight  provided  by  an  ESC  or  IPT  is 
intended  to  assess  the  validity  and  completeness  of  key  program 
issues,  alternatives,  assumptions.  Measures  of  Effectiveness 
(MOEs) ,  integration  and  interoperability  issues,  international 
interoperability,  process  redesign  approaches,  scenarios,  concept 
of  operations  or  employment,  and  threat  characteristics. 

c.  In  the  event  consensus  cannot  be  readily  obtained  at 
this  oversight  level,  issues  should  be  framed  and  raised  for 
ASN (RD&A)  or  MDA  and  CNO  (N8)/CMC  (DC,  CD&I),  or  designee, 
resolution . 

d.  For  Marine  Corps  programs,  the  AoA  ESC  or  IPT  is 
similarly  composed  with  CMC  (DC,  P&R) ;  CG,  MCCDC;  Marine  Corps 
Systems  Command  (MARCORSYSCOM) ;  and  Marine  Corps  Operational  Test 
and  Evaluation  Activity  (MCOTEA)  substituting  for  their  Navy 
counterparts . 

1 . 5  Analysis  Director  Role  in  the  Process 

An  analysis  director  should  be  assigned  by  ASN (RD&A)  for 
potential  ACAT  I  and  II  programs  or  PEO/SYSCOM  Commander  for 
potential  ACAT  III  and  IV  programs  to  plan,  lead  the  conduct  of 
an  AoA,  and  coordinate  funding  for  analysis  efforts.  Analysis 
directors  are  to  be  free  to  independently  conduct  AoAs,  but  will 
receive  advice  and  counsel  from  an  ESC  or  IPT  during  such  conduct 
pursuant  to  the  AoA  Study  Guidance  and  the  AoA  Study  Plan. 

a.  Analysis  directors  should: 
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(1)  Be  independent  of  the  PM. 

(2)  Have  a  strong  background  in  analysis. 

(3)  Have  technical  and  operational  credibility. 

b.  The  AoA  scope  of  analysis  is  approved  as  part  of  the 
AoA  Study  Plan.  The  Program  or  Resource  Sponsor  and  the  Analysis 
Director  drafts  the  AoA  Study  Plan. 


c.  Along  with  their  other  duties,  analysis  directors 

should : 


(1)  Present  periodic  analysis  briefings  (see  paragraph 
1.9  on  briefings/reports  below). 

(2)  Ensure  that  measures  are  taken  to  coordinate 
ACAT  I  program  analysis  efforts  with  all  appropriate  external 
agencies . 


(3)  Organize  an  analysis  team  to  assist  in  planning, 
conducting,  and  evaluating  the  analysis.  This  analysis  team 
should  include  representatives  from  the  organizations  represented 
in  the  AoA  ESC  or  IPT,  as  necessary. 

d.  In  the  event  a  contractor  is  employed  as  an  analysis 
director,  actions  should  be  taken  to  avoid  both  the  appearance 
and  existence  of  a  conflict  of  interest  or  potential  future 
conflict  of  interest. 

I .  6  CNO  Role  in  the  Analysis  of  Alternatives  Process 

CNO  (N8)  is  jointly  responsible  with  the  ASN (RD&A)  for 
top-level  oversight  of  the  AoA  process  as  supported  by  the  ESC. 
CNO  (N8)  will  facilitate  the  process  of  arriving  at  consolidated 
CNO  positions  on  matters  relating  to  alternatives  analysis  and  is 
the  final  CNO  approval  authority  for  joint  approval  of  ACAT  I, 

II,  and  III  AoA  Final  Reports.  For  ACAT  IV  programs,  the  Program 
or  Resource  Sponsor  will  perform  these  tasks  for  CNO  (N8) . 

a.  CNO  program  or  resource  sponsors  will  be  responsible 
for  providing  active  user  representation  on  AoA  ESCs  or  IPTs, 
proposing  an  AoA  scope  of  analysis,  and  planning  and  programming 
efforts.  (PEOs/SYSCOMs  or  DRPMs/PMs,  as  appropriate,  in 
conjunction  with  the  cognizant  program  or  resource  sponsors,  are 
responsible  for  budgeting  for  and  execution  of  required  funding 
to  conduct  AoAs . ) 
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b.  The  Director  of  Naval  Intelligence  will  validate  the 
threat  capability  described  in  an  AoA. 

c.  Director  Innovation,  Test  and  Evaluation,  and 
Technology  Requirements  (CNO  (N84))  will  provide  advice  and 
counsel  with  respect  to  MOEs  and  MOPs  used  in  AoAs .  The  intent 
is  to  ensure  that  criteria  used  to  justify  acquisition  decisions 
are  either  directly  testable  through  MOEs  or  are  indirectly 
testable  through  MOPs.  CNO  (N84)  will  forward  MOEs  and  MOPs 
developed  during  the  AoA  to  COMOPTEVFOR  for  review  with  respect 
to  their  testability. 

d.  Director,  Assessment  Division  (CNO  (N81))  is  the  CNO 
approval  authority  for  AoA  Study  Plans  and  approval  of  all  models 
and  scenarios  used  in  AoAs .  CNO  (N81)  will  be  invited  to  join 
the  AoA  ESC  or  IPT. 

e.  CNO  (N8)  is  the  Executive  Oversight  Director  of  AoAs 
for  warfare  requirements.  This  does  not  relinquish  the  Program 
Sponsor's  AoA  responsibilities,  but  ensures  CNO  (N8)'s 
integration  function  is  used  to  its  fullest. 

f.  Director,  Total  Force  Programming,  Manpower,  and 
Information  Resources  Management  (CNO  (N12))  is  the  point  of 
contact  for  matters  relating  to  manpower  requirements  analysis. 
The  intent  is  to  ensure  the  ESC  or  the  IPT  fully  explores 
manpower  implications  of  new  weapons  systems  and  alternatives 
that  favor  reductions  in  manpower  and  personnel,  and  total 
ownership  cost. 

g.  Director  of  Naval  Education  and  Training  (CNO  (N12)) 
is  the  point  of  contact  for  matters  relating  to  individual 
training  and  education  requirements  analysis.  The  intent  is  to 
ensure  the  ESC  or  IPT  fully  explores  individual  training  and 
education  implications  of  new  weapon  systems  and  alternatives  to 
optimize  human  performance  and  total  system  performance  at 
minimum  total  ownership  costs. 

h.  Deputy  Chief  of  Naval  Operations  (Fleet  Readiness  and 
Logistics)  (CNO  (N4))  and  (Energy  &  Environmental  Readiness 
Division)  (OPNAV  (N45) )  are  the  point  of  contact  for  matters 
relating  to  compliance  with  environmental  laws,  regulations,  and 
policies  applicable  to  new  system  acquisition.  The  intent  is  to 
ensure  AoA  IPTs  fully  explore  the  operational,  schedule,  and  cost 
implications  of  environmental  compliance  requirements  during 
early  design  phase  of  system  development  and  for  end-user 
operations . 

1 . 7  CMC  Role  in  the  Analysis  of  Alternatives  Process 
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CMC  (DC,  CD&I)  is  jointly  responsible  with  the  ASN (RD&A) 
for  overseeing  Marine  Corps  analysis  activities.  In  this  role, 
CMC  (DC,  CD&I)  facilitates  the  process  of  arriving  at 
consolidated  CMC  positions  on  AoA  matters  and  acts  as  the  final 
CMC  approval  authority  for  AoA  directors,  analysis  plans,  and 
formal  reports  for  ACAT  I,  II,  III,  and  IV  analyses. 

a.  In  support  of  analyses  that  require  Marine  Corps- 
unique  operations,  CMC  (DC,  CD&I)  will  develop  and  accredit 
scenarios  consistent  with  Defense  Planning  Guidance. 

b.  CMC  (CG,  MCCDC)  will  provide  for  active  user 
representation  to  the  analysis  director,  as  well  as  planning, 
programming,  budgeting,  and  execution  funding  for  AoA  activities 
conducted  prior  to  program  initiation. 

c.  As  the  resource  allocator,  CMC  (DC,  P&R)  will  plan, 
program,  and  budget  funding  to  support  AoA  efforts  following 
program  initiation.  In  conjunction  with  PEOs/DRPMs/PMs,  as 
appropriate,  CMC  (DC,  P&R)  will  budget  for  these  analysis 
efforts . 


d.  The  Director  of  the  United  States  Marine  Corps 
Intelligence  Activity  (USMCIA)  will  validate  the  threat 
capability  described  in  Marine  Corps  analyses. 

e.  MCOTEA  personnel  will  provide  advice  and  counsel  with 
respect  to  MOEs  and  MOPs  used  in  analyses.  The  intent  is  to 
ensure  that  criteria  used  to  justify  acquisition  decisions  are 
either  directly  testable  through  MOEs  or  are  indirectly  testable 
through  MOPs.  CMC  (CG,  MCCDC)  will  forward  MOEs  and  MOPs 
developed  during  the  AoA  for  Marine  Corps  programs  to  Director, 
MCOTEA  for  review  with  respect  to  their  testability. 

f.  For  ACAT  I,  II,  III,  and  IV  programs,  the  Marine  Corps 
AoA  Standing  IPT  provides  advice  and  counsel  to  CMC  (DC,  CD&I) . 
They  review  and  prioritize  analyses  considering  urgency  of  need, 
to  ensure  maximum  efficiency  in  cost,  time,  and  level  of  effort. 
The  Standing  IPT  also  advises  the  MDA  on  tailoring  an  AoA. 

During  the  conduct  of  formal  analyses  of  alternatives,  the  IPT 
should  provide  guidance  to  the  analysis  director. 

1 . 8  PEO/SYSCOM/PM  Role  in  the  Analysis  of  Alternatives  Process 

As  a  member  of  the  AoA  ESC  or  IPT,  the  PEO/SYSCOM/PM  will 
provide  the  analysis  director  valuable  advice  and  counsel, 
particularly  regarding  the  executability  of  proposed 
alternatives,  and  technical  issues  such  as  manpower  requirements, 
human  performance  and  environmental,  safety,  and  occupational 
health  considerations,  and  training  support.  In  conjunction  with 
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the  program  or  resource  sponsor,  PEOs/SYSCOMs/PMs  will  provide 
and  execute  analysis  funding  in  support  of  the  analysis 
director's  plan.  PEOs/SYSCOMs/PMs  will  also  be  responsible  for 
ensuring  appropriate  conflict  of  interest  clauses  are  included  in 
contracts  for  AoA-related  services.  The  PEO/SYSCOM/PM  in 
coordination  with  a  contracting  officer  will  be  responsible  for 
providing  feedback  to  industry  so  that  AoA  efforts  can  be 
coordinated  with  ongoing  industrial  materiel  analysis  solution 
studies  which  may  be  conducted  under  government  contract.  The 
intent  is  for  both  efforts  to  be  comprehensive  and  complementary. 

1 . 9  Brief ings /Reports 

a.  Typically  an  AoA  proceeds  in  the  following  five 

phases : 

(1)  Planning. 

(2)  Determination  of  performance  drivers. 

(3)  Determination  of  cost  drivers. 

(4)  Resolution  of  cost/perf ormance  issues. 

(5)  Preparation  of  final  briefing  and  final  report. 

b.  To  ensure  timely  completion  of  the  AoA  to  support 
program  initiation,  analysis  directors  will  provide  status 
briefings  to  the  AoA  ESC  or  IPT,  ASN (RD&A) ,  PEO/SYSCOM/DRPM,  CNO 
(N8),  and  CMC  (DC,  CD&I),  as  requested. 

c.  At  the  end  of  the  process,  the  AoA  ESC  or  IPT  reviews 
the  final  report  and  presents  a  final  briefing  of  results.  The 
intent  is  to  ensure  all  issues  are  addressed  and  that  key  finding 
are  supported  by  the  analysis.  The  AoA  final  results  may  be 
presented  in  the  form  of  either  a  briefing  and/or  a  formal  report 
with  approval  as  indicated  in  Table  E5T2 . 


Table  E5T2  AoA  Final  Report  Approval  Authorities 

ACAT  ID  and  IAM 

ACAT  IC,  I AC,  II,  and  III 

ACAT IV 

ASN(RD&A),  or  designee  (flag  or  SES). 

&  CNO  (N8)  or  CMC  (DC,  CD&I) 

MDA,  or  designee  (flag  or  SES), 

&  CNO  (N8)  or  CMC  (DC,  CD&I) 

MDA,  or  designee,  &  CNO  Program 
Sponsor  or  CMC  (DC,  CD&I) 

d.  In  the  case  of  ACAT  ID  and  IAM  programs,  ASN (RD&A)  and 
CNO  (N8)  or  CMC  (DC,  CD&I),  as  appropriate,  approve  the  AoA 
performance  parameters  at  Gate  2  which  shall  occur  at  least  120 
days  prior  to  the  Defense  Acquisition  Board  (DAB) ,  Defense  Space 
Acquisition  Board  (DSAB) ,  or  Information  Technology  Acquisition 
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Board  (ITAB)  date.  This  supports  the  follow-on  development  of 
the  CDD/CPD/APB,  as  well  as  final  Joint  Requirements  Oversight 
Council  (JROC)  approval  and  validation  of  the  key  performance 
parameters . 

e.  A  copy  of  all  ACAT  I,  II,  III,  and  IV  AoA  final 
reports  will  be  provided  to  DASN (RDT&E)  CHSENG,  CNO  (N81)  or  CMC 
(DC,  CD&I) ,  and  COMOPTEVFOR,  or  Director,  MCOTEA,  as  appropriate. 
A  copy  of  ACAT  ID  and  IAM  AoA  final  reports  shall  be  provided  to 
DCAPE  not  later  than  60  days  prior  to  the  DAB  milestone  review. 

1.10  Navy  Analysis  of  Alternatives  Process 

The  general  Navy  AoA  process  diagram,  which  may  be 
tailored  depending  upon  the  ACAT  level,  is  shown  on  the  next 
page . 
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ASN(RD&A)/OPNAV  AOA  INITIATION,  ANALYSIS,  AND  APPROVAL  PROCESS 


INITIATION 


SCOPE  PREPARATION: 
ACAT  I,  II,  III  -  Program 
Sponsor 


SCOPE  COORDINATION: 

ACAT  I  -  INTEGRATED  PRODUCT 
TEAM  (IPT) 

ACAT  II,  III  -  IPT 


SCOPE  REVIEW: 
-  N81/DASN 


SCOPE  APPROVAL: 

-  N81/ASN(RD&A),  or  designee  (ACAT  I,  II) 

-  N81/MDA  (ACAT  III) 


SCOPE  PREPARATION: 

ACAT  IV  -  Program 

Sponsor 

1 _ 1 

IPT  RECOMMENDS: 

-  ANALYSIS  DIRECTOR  (BY  NAME) 

-  ANALYSIS  TEAM  (BY  ORGANIZATION) 

-AOA  SCHEDULE 

-  AOA  COST  ESTIMATE 

-  ISSUES  TO  BE  ADDRESSED 

SCOPE  APPROVAL: 
N81/MDA  (ACAT  IV) 


ANALYSIS  DIRECTOR: 
(FFRDC/SYSCOM/LABS/CONTRACTOR) 

-  PLAN/SUPERVISE  STUDY 

-  COORDINATE  FUNDING  WITH 
PROGRAM  MANAGER 


ANALYSIS 


ANALYSIS  TEAM  (NOMINAL): 

-  ASN  (RD&A)  REP 

-  N80/N81  REPS 

-  N2/N6  REP 

-  N4/N45  REPS 

-  N84  REP 

-  PROGRAM  SPONSOR  REP 

-  PEO/SYSCOM/DRPM  REP 

-  PM  REP 

-  OTHERS  AS  APPROPRIATE 

I _ 

*CNA  *USMC  *DON  CIO  REP 

‘WARFARE  CENTERS 

(NOTE:  ANALYSIS  TEAM  AT  DISCRETION  OF  MDA  FOR  ACAT  IV) 


AOA  PLAN: 

-  ISSUES 

-  ALTERNATIVES 

-  SCENARIOS 

-  MODELS 

-  MOEs 

-  WORKPLAN 
- POA&M 


APPROVAL 


BRIEF/PROGRESS  REPORT 
(ACAT  I,  II,  III) 


AOA  IPT: 

-  DASN  (RD&A)/PM 

-  ASN(FM&C)/ASN(M&RA) 

-  ASN(EI&E) 

-  N8/N80/N81/N82 

-  N1/N4/N2/N6 

-  N84 

,  -  PROGRAM  SPONSOR 

-  PEO/SYSCOM/DRPM 

-  OPA 

-  GENERAL  COUNSEL 

-  COMOPTEVFOR 

-  DASN(AP)/DIRECTOR 

-  DASN  ACTION  OFFICER 


FINAL  BRIEF  AND  APPROVAL: 

ACAT  I,  II  -  N8/ASN  (RD&A),  or  designee 
ACAT  III  -  N8/MDA 


AOA 

FINAL  REPORT 
(IF  REQUIRED) 


-  NCCA 

BRIEF/PROGRESS  REPORT 

-  DON  CIO 

FINAL  BRIEF  AND  APPROVAL: 

AOA 

(ACAT  IV) 

- 

ACAT  IV  -  Program  Sponsor/MDA 

(IF  REQUIRED) 
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Chapter  6 

Systems  Engineering  and  Human  Systems  Integration 


References:  (a) 

SECNAVINST 

5000. 2E 

(b) 

OPNAVINST 

3960.1 6A 

(c) 

SECNAVINST 

4855. 3B 

(d) 

SECNAVINST 

4855.5  ; 

(e)  MCO  4855. 10B,  Product  Quality  Deficiency  Report 
(PQDR) ,  of  26  Jan  1993 

( f )  NAVSO  P-3692,  Independent  Logistics  Assessment 
Handbook,  of  Dec  2003 

(g)  POD  Directive  5000.01  of  12  May  2003 

(h)  CJCSI  3170. 01H 

(i)  SPAWARINST  5400 . 1A/NAVAIRINST  5400. 158A/ 
NAVSEAINST  5400 . 97C/NAVSUPINST  5400.15/ 
NAVFACINST  5400.10,  Virtual  SYSCOM  Engineering 
and  Technical  Authority  Policy,  of  31  Oct 
2006/31  Jan  2007/27  Nov  2006/12  Dec  2006/7  Nov 
2006 

( j )  MARCORSYSCOM,  C4I  Integration  and 
Interoperability  Management  Plan,  of  2  Sep  2005 


(k) 

DOD  Instruction  8510.01  of  28  Nov  2007 

(1) 

MIL-HDBK-237D,  Electromagnetic  Environmental 

Effects  and  Spectrum  Certification 

Guidance  for 

the  Acquisition  Process,  of  20  May 

2005 

(m) 

SECNAVINST  5200. 39A 

(n) 

OPNAVINST  1001. 21B 

(o) 

USD(P&R)  Memorandum,  Interim  Policy 

and 

Procedures  for  Strategic  Manpower  Planning  and 


Development  of  Manpower  Estimates,  of  10 

Dec 

2003 

(p) 

OPNAVINST  1500. 7 6B 

(q) 

DOD  Instruction  5000.02  of  8  Dec  2008 

(r) 

Assistant  Secretary  of  the  Navy  (Installations 

and  Environment)  Memorandum  99-01,  Requirements 

for  Environmental  Considerations  in  Test 

Site 

Selection,  of  11  May  1999 

(s) 

OPNAVINST  5100. 23G 

(t) 

SECNAVINST  5100. 10 J 

(u) 

OPNAVINST  5090. 1C 

(v) 

DOD  4160. 28-M,  Volume  1,  Defense 

Demilitarization:  Program  Administration 

Manual 

of  7  Jun  2011 

(w)  POD  4160. 21-M,  Defense  Materiel  Disposition 
Manual,  of  18  Aug  1997 

(x)  NAVSEA  OP  4,  Ammunition  and  Explosives  Safety 
Afloat,  of  15  Jan  2003 

(y)  OPNAVINST  8020.14/MCQ  P8020.ll 

(z)  SECNAVINST  4140.2 
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(aa)  POD  4140. 1-R  of  23  May  2003 

(ab)  Public  Law  108-136,  National  Defense 
Authorization  Act  for  Fiscal  Year  2004,  Section 
802,  Quality  Control  In  Procurement  Of  Aviation 
Critical  Safety  Items  And  Related  Services,  of 
24  Nov  2003 


6 . 1  Systems  Engineering 

Program  managers  (PMs)  shall  define  and  implement  a 
disciplined  approach  for  assuring  and  measuring  the  quality  and 
reliability  of  systems  during  development  and  production  per 
reference  (a)  . 

A  Systems  Engineering  Plan  (SEP)  is  the  means  for  a 
disciplined  approach  for  planning  and  managing  the  systems 
engineering  effort.  The  SEP  shall  address  the  overall  systems 
engineering  process  to  be  used,  how  this  process  relates  to  the 
overall  program,  how  the  technical  baseline  will  be  managed,  and 
how  technical  reviews  will  be  used  as  a  means  to  ascertaining 
program  technical  risk  per  reference  (a) . 

Per  reference  (a) ,  all  programs  responding  to  a 
capabilities  or  requirements  document,  regardless  of  acquisition 
category,  shall  apply  a  robust  systems  engineering  approach  that 
balances  total  system  performance  and  total  ownership  costs 
within  the  family  of  systems  (FoS)  ,  systems  of  systems  (SoS) 
context.  Programs  shall  develop  a  SEP  for  approval  by  the  Deputy 
Assistant  Secretary  of  Defense  for  Systems  Engineering  for  ACAT 
ID,  IC,  I AM,  and  IAC  programs;  by  DASN (RDT&E)  CHSENG  for 
Component  Approval  of  ACAT  ID,  IC,  IAM,  and  IAC  programs;  by 
DASN (RDT&E)  CHSENG  for  milestone  decision  authority  (MDA) 
approval  of  ACAT  II  programs;  the  MDA  of  ACAT  III  and  IV 
programs;  in  conjunction  with  each  milestone  review,  and 
integrated  with  the  acquisition  strategy  (see  paragraph  2.9.1). 
This  plan  should  describe  the  program' s  overall  technical 
approach,  including  processes,  resources,  metrics,  and  applicable 
performance  incentives.  It  should  also  detail  the  timing, 
conduct,  and  success  criteria  of  technical  reviews.  SEPs  are 
submitted  by  the  Direct  Reporting  Program  Manager  (DRPM) /PM  and 
program  lead  or  chief  systems  engineer  and  concurred  with  by  the 
Program  Executive  Officer  (PEO) ,  or  equivalent,  and  the 
PEO/Systems  Command  (SYSCOM)  lead  or  chief  systems  engineer.  See 
annex  6-A  for  the  signature  cover  pages  associated  with  the 
appropriate  ACAT  level  program.  See  ASN (RD&A)  memorandum  of  16 
Nov  2007  for  SEP  development,  review,  and  approval  guidance. 

See  the  OUSD(AT&L)  Office  of  the  Deputy  Assistant  Secretary  of 
Defense  (Systems  Engineering)  revised  SEP  Outline,  Version  1.0  at 
the  following  Web  site  http : / /www. acq. osd.mil/se/ do cs/PDUSD- 
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Hazards  and  risk  assessments,  including  environmental, 
safety,  and  health  considerations,  should  be  conducted  to 
identify  and  mitigate  factors  that  could  impact  the  development, 
production,  operation,  and  sustainment  of  the  system  with  respect 
to  total  system  cost,  schedule,  and  performance.  PMs  should 
provide  for  independent  developing  activity  (DA)  technical  review 
and  independent  DA  technical  risk  assessment  of  programs.  Formal 
systems  engineering  technical  reviews  should  be  used  as  the  means 
for  continuous  assessment  of  program  technical  health.  These 
reviews,  when  conducted  by  the  program  team  together  with 
independent  DA  subject  matter  experts  at  appropriate  event-based 
points  in  a  program,  can  be  an  effective  approach  to  managing  the 
technical  baseline  (performance  requirements,  design  trade-offs, 
certification  and  validation  requirements,  development  and 
production  costs,  and  schedule  as  an  integrated  whole) ,  technical 
risk,  and  overall  program  technical  health.  For  more  information 
on  Item  Unique  Identification  (IUID)  Implementation  Plan  see  DoDI 
8320.04  and  updated  Defense  Acquisition  Guidebook  (DAG),  chapter 
5,  Life-Cycle  Logistics. 

See  the  Defense  Acquisition  Guidebook  for  implementation 
guidance  for  all  Department  of  the  Navy  (DON)  programs. 

6.1.1  Manufacturing  and  Production 

Manufacturing  and  production  activities  are  those 
activities  associated  with  the  concurrent  development  and 
maturation  of  the  product  design  for  production,  manufacturing, 
and  the  establishment  of  the  required  production  and  post¬ 
production  resources  and  capabilities.  It  also  includes 
transition-to-production  planning  to  smoothly  move  from  the 
design/development  phase  into  low-  and  high-rate  production  with 
minimal  risks.  This  planning  should  ensure: 

a.  The  details  of  the  design  and  production  planning 
process  are  integrated  into  the  program  plan  and  master  schedule, 

b.  Key  product  characteristics,  critical  safety  items, 
and  critical  application  items  are  identified  during  the  design 
phase. 


c.  Design  for  producibility,  manufacture  and  assembly  is 
performed.  Design  trade  studies  should  be  accomplished  to  ensure 
product  designs  that  are  tolerant  to  variation  expected  in  the 
intended  manufacturing,  assembly,  test,  and  usage  environments, 

d.  Key  manufacturing  process  characteristics  are 
identified  and  the  associated  manufacturing  processes 


6-3 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


requirements  are  defined  and  developed  concurrent  with  product 
design.  Variability  reduction  planning  should  identify  the 
approach  toward  implementing  process  controls  on  key  system 
design  characteristics, 

e.  Hard  tooling,  test  equipment,  and 
calibration/metrology/measurement  system  is  validated  for  low 
rate  and  full  rate  production, 

f.  Manufacturing  processes  are  proof ed/validated 

g.  Effectiveness  of  Manufacturing  Resource  Planning/ 
Enterprise  Resource  Planning, 

h.  Identification  of  production  capacity  and  bottlenecks 
with  work-arounds, 

i.  Diminishing  manufacturing  sources/parts  obsolescence 
planning, 

j .  Discrepancy  root  cause  and  corrective  action  system 
implementation, 

k.  Management  of  subcontractors/suppliers,  and  special 
processing  facilities  (e.g.,  heat  treatment,  etc),  and 

j .  Production  readiness  reviews  conducted  to  assess 
readiness  of  the  baselined  product  and  the  associated 
manufacturing  resources/processes  to  begin  low-  and/or  high-rate 
production . 

6. 1.1.1  Test,  Measurement,  and  Diagnostic  System  Support 

PMs  should  establish  metrology  and  calibration  (METCAL) 
requirements  early  in  the  acquisition  cycle  to  assure  that 
measurements  and  related  test  and  calibration  decision  risks  are 
commensurate  with  the  needs  of  each  phase  of  an  acquisition 
program.  These  requirements  are  per  reference  (b)  and  include 
the  following: 

6. 1.1. 1.1  Measurement  Traceability  and  Compatibility 

Measurements  should  be  traceable  through  national 
standards  maintained  by  the  National  Institute  of  Standards  and 
Technology  (NIST)  to  the  International  System  of  Units  (SI)  of 
measurements,  or  to  natural  constants  whose  values  in  terms  of 
the  SI  units  are  known  and  recommended  by  the  General  Conference 
of  Weights  and  Measures,  and  compatible  within  the  affected 
contractor  and  defense  organizations,  and  applicable  allied 
nations . 
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6. 1.1. 1.2  Measurement  Technology 

Measurement  technology  should  be  available,  suitable,  and 
effective  to  support  test,  measurement,  and  calibration 
requirements  of  all  phases  of  an  acquisition.  New  or  improved 
measurement  technology  required  by  an  acquisition  program  should 
be  developed  concurrently  with  the  program. 

6.1.2  Quality 

The  quality  program  should  ensure  the  use  of  best 
engineering,  design,  manufacturing  and  management  practices  that 
emphasize  the  prevention  of  defects.  Quality  should  be  designed 
into  the  product  through  the  systems  engineering  design  process 
to  define  the  product  and  process  quality  requirements. 
Contractors  should  propose  a  quality  management  process  that 
meets  required  program  support  capabilities.  The  quality 
management  system  may  be  based  on  the  fundamentals  described  in 
the  ISO-9001  series  supplemented  by  AS9100,  International 
Aerospace  Quality  Standard,  which  provide  a  basic  minimum  quality 
system  model.  Additional  advanced  quality  requirements  should  be 
considered  for  systems  based  on  factors  such  as  risk,  design 
complexity,  and  maturity,  process  complexity  and  maturity, 
safety,  and  economics.  An  advanced  quality  system  builds  on  a 
basic  quality  system,  especially  during  the  design/development 
phase,  by  identifying  critical  product  and  process 
characteristics,  design-to-manufacturing  process  capabilities, 
design  for  assembly  and  manufacturing,  design  to  control  process 
variability,  process  controls,  continuous  improvements,  etc.  The 
quality  management  approach  should  include  an  assessment  of  the 
contractor's  quality  management  process  and  its  implementation, 
including  those  related  to  assessments  or  oversight  of 
subcontractors,  suppliers,  and  special  process  facilities  (e.g., 
heat  treatment) .  The  quality  system  should  provide  timely 
notification  and  feedback  to  contracting  and  program  offices  in 
areas  such  as  major  and  critical  deficiencies,  potential 
manufacturing  process  problems,  and  subcontractor,  supplier,  or 
special  process  facilities  problems  that  potentially  impact  the 
program . 

6. 1.2.1  Past  Performance 

Reference  (c)  provides  specific  procedures  for  obtaining 
past  performance  quality  information,  using  the  Product  Data 
Reporting  and  Evaluation  Program. 

6. 1.2. 2  Deficiency  Reporting 


6-5 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


PMs  should  report  discrepancies  or  deficiencies  in 
material  shipments  and  request  billing  adjustments  and  implement 
corrective/preventative  actions  to  preclude  recurrence  of  quality 
deficiencies . 


Reference  (c)  provides  policies,  procedures  and 
responsibilities  for  implementing  and  monitoring  a  unified, 
automated  product  data  reporting  and  evaluation  system. 

Reference  (d)  provides  procedures  for  reporting  product 
deficiencies  across  component  lines. 

Reference  (e)  provides  specific  Marine  Corps  product 
quality  deficiency  reporting  procedures. 

6.1.3  Acquisition  Logistics  and  Sustainment 

Reference  (f)  provides  the  PM  with  a  framework  and  road 
map  for  structuring  and  executing  successful  logistics  support 
programs  throughout  the  system  life  cycle. 

6. 1.3.1  Life  Cycle  Logistics  (LCL) 

LCL  includes  the  logistics  functions  from  the  acquisition 
phase  through  the  sustainment  phase.  LCL  means  that  major 
program  decisions  are  assessed,  weighed,  and  justified  in  terms 
of  that  decision''  s  effect  on  resultant  system  or  increment 
operational  effectiveness,  long-term  sustained  material 
readiness,  and  the  affordability  to  operate  and  maintain  across 
the  expected  life  cycle. 


6. 1.3. 2  Total  Life  Cycle  Systems  Management  (TLCSM) 

Per  reference  (g) ,  TLCSM  is  the  implementation, 
management,  and  oversight  of  all  activities  associated  with  the 
acquisition,  development,  production,  fielding,  sustainment,  and 
disposal  of  a  defense  system  across  its  life  cycle.  TLCSM  bases 
major  system  development  decisions  on  their  effect  on  life  cycle 
operational  effectiveness  and  logistics  affordability.  The  TLCSM 
decision  model  encompasses,  but  is  not  limited  to,  the  following: 


a.  Evolutionary  acquisition  strategies,  including 
support. 


b . 

reference 


Supportability  performance  criteria,  as  defined  in 
(h)  under  "operational  effectiveness". 


c.  Cost-related  performance  and  metrics  (some  variant  of 
cost-per-operating-period) , 
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d.  Performance-based  logistics  strategies  and  associated 
metrics , 

e.  Increased  reliability  and  reduced  logistics  footprint, 

and 

f.  Continuous  review  and  revision  of  sustainment 
strategies . 

Implementation  of  the  TLCSM  business  approach;  by 
capabilities  development,  and  program  and  contracting  management; 
means  that  all  major  materiel  alternative  considerations  and  all 
major  acquisition  functional  decisions  demonstrate  an 
understanding  of  the  effects,  during  consequential  operations  and 
sustainment  phase,  of  system  effectiveness  and  affordability. 

6. 1.3. 3  Program  Manager's  LCL  Integrated  Product  Support 
Responsibility 

Per  reference  (g) ,  PMs,  as  supported  by  a  product  support 
manager  (PSM)  for  ACAT  I  and  II  programs,  establish  innovative 
life  cycle  logistics  integrated  product  support  and  sustainment 
programs,  using  best  practice  and  technology  solutions.  The 
choice  of  logistics  integrated  product  support  strategy  is  based 
and  presented  on  well-documented  analyses  that  system  operational 
effectiveness  and  life  cycle  affordability  can  be  satisfied  using 
Department  of  Defense  (DoD)'s  and  private  industry's  operational 
and  logistics  infrastructure.  Decisions  are  updated  to  satisfy 
iterative  changes  in  formal  criteria;  with  the  result  that  system 
performance  is  interoperable  and  meets  Joint  Capabilities 
Integration  and  Development  System  (JCIDS)  and  JCIDS-related 
performance  capabilities  criteria. 

6. 1.3. 4  Warfighter  Supportability-Related  Performance 

Understanding  warfighter  needs  for  short  and  long-term 
sustained  material  readiness,  sustained  operational  effectiveness 
and  availability,  and  continued  operational  affordability  is 
essential  to  any  logistics  integrated  product  support  strategy. 
PMs  must  transcribe  changed  performance  specifications  into  the 
logistics  integrated  product  support  strategy  and  program,  as 
situations  change  and  as  the  operational  environment  evolves. 

For  example:  PMs  needing  to  invest  in  technological  upgrades  for 
embedded  diagnostics  should  rely  for  investment  justification  on 
formally  specified  warfighter  criteria  for  high  reliability  and 
built-in-test  performance. 

6. 1.3. 5  Supportability 
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Effective  sustainment  of  weapons  systems  (including 
minimal  "logistics  footprint")  begins  with  the  design, 
development,  and/or  procurement  of  reliable,  maintainable,  and 
diagnostically  effective  systems.  This  is  achieved  in  part 
through  a  robust  systems  engineering  methodology  that  focuses  on 
total  system/total  life-cycle  performance.  Supportability  and 
cost-related  specifications  are  an  integral  part  of  the  systems 
engineering  process. 

6. 1.3. 6  Supportability  Analyses 

Supportability  analyses  are  a  key  part  of  the  overall 
acguisition  strategy,  source  selection,  and  system  design  and 
should  be  accomplished  in  support  of  these  activities  throughout 
the  acquisition  process. 

Supportability  analyses  should  support  acquisition 
planning,  level  of  repair  and  reliability-centered  maintenance 
decisions,  program  tradeoffs,  and  the  formation  of  contract 
provisions . 

See  the  Defense  Acquisition  Guidebook  for  implementation 
guidance  for  all  DON  programs. 

6. 1.3. 7  Integrated  Product  Support  Concepts 

Integrated  product  support  concepts,  including  Performance 
Based  Logistics  (PBL)  and  the  associated  business  case  analysis 
discussed  in  paragraph  3.4.7,  should  satisfy  user's  CDD/CPD- 
specified  requirements  for  sustaining  support  performance  at  the 
lowest  possible  life-cycle  cost.  To  this  end,  acquisition 
planning  documents  should  document,  for  each  evolutionary 
increment  of  capability  to  be  delivered,  the  plans,  resources, 
and  metrics  that  will  be  used  to  execute  and  measure  these  five 
mandatory  logistics  support  concepts: 

a.  Minimal  total  life-cycle  cost  to  own  and  operate 
(i.e.,  minimal  total  ownership  cost), 

b.  Maintenance  concepts  that  optimize  both  organic  and 
industry  sources, 

c.  Availability  of  support  to  meet  warfighter-specified 
levels  of  war  and  peacetime  performance, 

d.  Logistics  support  that  sustains  and  continuously 
improves  both  short  and  long-term  material  readiness,  and 

e.  Training  concepts  that  describe  the  training  to  meet 
short  and  long-term  sustained  material  readiness 
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See  the  Defense  Acquisition  Guidebook  for  implementation 
guidance  for  all  DON  programs. 

6. 1.3. 8  Integrated  Product  Support  Data 

The  DON'S  database  for  the  dissemination  of  weapon  system 
operating  and  support  (O&S)  costs  is  the  DON  Visibility  and 
Management  of  Operating  and  Support  Costs  (VAMOSC) .  Naval  Center 
for  Cost  Analysis  (NCCA)  should  have  overall  program  management 
responsibility  for  VAMOSC.  See  the  Defense  Acquisition  Guidebook 
for  implementation  guidance  for  all  DON  programs. 

6. 1.3. 8.1  Sources  for  Integrated  Product  Support 
Related  Data 


Obtain  supportability-related  program  data  through  the  use 
of  Logistics  Management  Information  (LMI)  summaries.  Refer  to 
MIL-PRF-49506,  Logistics  Management  Information,  and  MIL-HDBK- 
502,  DOD  Handbook  -  Acquisition  Logistics,  for  guidance. 

6. 1.3. 9  Integrated  Product  Support  Resources 

Integrated  product  support  analyses  should  determine 
integrated  logistics  support  resource  requirements  for  the 
program's  initial  planning,  execution,  and  life-cycle  integrated 
product  support.  Recommendations  for  entry  into  subsequent 
phases  should  be  based  on  adequate  integrated  product  support 
resources  being  budgeted  to  meet  and  sustain  support  performance 
threshold  values.  Planning,  Programming,  Budgeting,  and 
Execution  System  (PPBES)  budget  item  documentation  or  the 
Logistics  Requirements  and  Funding  Summary  annex  of  the  Life- 
Cycle  Sustainment  Plan,  will  show  whether  or  not  adequate  funding 
has  been  budgeted  to  fully  support  the  end  item.  See  the  Defense 
Acquisition  Guidebook  for  implementation  guidance  for  all  DON 
programs . 

6.1.4  Open  Architecture 

See  reference  (a)  for  guidance  and  direction. 

Naval  open  architecture  is  an  extension  and  Navy 
implementation  of  the  USD(AT&L)'s  Modular  Open  Systems  Approach. 
Naval  open  architecture  should  be  applied  as  an  integrated 
technical  approach  and  used  for  all  systems,  including  support 
systems.  Naval  open  architecture  principles  include: 

Modular  design  and  design  disclosure  to  permit 
evolutionary  design,  technology  insertion,  competitive 
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innovation,  and  alternative  competitive  approaches  from  multiple 
qualified  sources. 

Reusable  application  software  derived  from  best  value 
candidates  reviewed  by  subject  matter  expert  peers  and  selected 
based  on  data-driven  analyses  and  experimentation.  Design 
disclosure  and  source  code  should  be  made  available  for 
evolutionary  improvement  to  all  qualified  sources. 

Interoperable  joint  warfighting  applications  and  secure 
information  exchange  using  common  services  (e.g.,  common  time 
reference),  common  warfighting  applications  (e.g.,  open 
architecture  track  manager)  and  information  assurance  as 
intrinsic  design  elements. 

Life-cycle  affordability  which  includes  system  design, 
development,  delivery,  and  support.  Concurrently  mitigating 
ongoing  Commercial-Of f-The-Shelf  (COTS)  obsolescence  by 
exploiting  the  Rapid  Capability  Insertion  Process/Advanced 
Processor  Build  (RCIP/APB)  methodology  for  sustained  performance 
enhancement . 

Encouraging  competition  and  collaboration  through 
development  of  alternative  solutions  and  sources. 

6.1.5  Reliability,  Availability,  Maintainability,  and  Cost 
(RAM-C) 


As  part  of  the  performance  requirements,  a  design 
reference  mission  profile  should  be  developed  that  includes 
functional  and  environmental  profiles. 

Parts  derating  criteria  should  be  mutually  agreed  upon 
between  the  contractor  and  the  government  and  must  consider  past 
component  history,  environmental  stresses,  and  component 
criticality  under  worst-case  mission  profile  environments. 

Accelerated  test  methods  (e.g.,  step  stress  testing, 
accelerated  life  testing,  and  reliability  growth  testing)  should 
be  used  to  assure  design  maturity  prior  to  operational  testing. 

Provisions  for  failure  data  collection,  reporting,  and 
analyses  should  be  established  and  mutually  agreed  upon  between 
the  government  and  the  contractor. 

Built-In-Test,  testability,  and  false  alarm  requirements 
should  be  defined  and  a  plan  to  achieve  requirements  maturity 
implemented.  A  guide  titled  "Technical  Brief  on  Built-In-Test, 
Design  and  Optimization  Guidelines  (October  2001)"  is  available 
on  the  DASN(RD&A)AP  Acquisition  One  Source  web  page  at 
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http : / / acquisition . navy.mil/ content /view/ full/825. 

See  the  Defense  Acquisition  Guidebook  for  implementation 
guidance  for  all  DON  programs. 

6.1.6  Interoperability  and  Integration 

See  reference  (a)  for  guidance  and  direction. 

[ from  SNI  5000. 2E,  6.1.6,  second  subparagraph:  During  the 
Materiel  Solution  Analysis  Phase  and  the  Technology  Development 
Phases,  interoperability  shall  be  addressed  by  including  SoS  or 
FoS  considerations  in  applicable  analyses.  If  Technology 
Development  activity  is  carried  out,  the  PM  shall  ensure  that  the 
technologies  developed  will  have  no  adverse  effect  on 
interoperability  and  integration  at  the  SoS  or  FoS  level.  During 
the  Engineering  and  Manufacturing  Development  (EMD)  phase,  the  PM 
shall  ensure  that  interoperability  is  being  maintained. ]  PMs 
should  plan  to  participate  as  data  producers  or  data  consumers  in 
Community  of  Interest  (COI)  pilots  for  technical  risk  reduction 
efforts  for  the  programs  involved. 

6. 1.6.1  IT  Design  Considerations 

See  reference  (a)  for  guidance  and  direction. 

6. 1.6. 2  DoD  Architecture  Framework  (DoDAF) /Global 
Information  Grid  Technical  Guidance  (GTG) 

DoD  Joint  Technical  Architecture  (JTA)  was  replaced  by  the 
Defense  Information  Technology  Standards  Registry  (DISR)  which  is 
now  included  in  the  GTG.  Pursuant  to  the  DAG,  NR  KPP  elements 
must  comply  with  the  GTG  and  include  DISR  mandated  Global 
Information  Grid  (GIG)  net  centric  IT  standards.  See  reference 
(a)  and  DON  CIO  memorandum  Department  of  the  Navy  DoD 
Architecture  Framework  V2 . 0  Implementation  Guidance  of  22  Mar 
2010  for  guidance  and  direction. 

6. 1.6. 2.1  Transformational  Communications  Architecture 

(TCA) 


TCA  is  essentially  a  network  of  interconnected 
capabilities  that  span  the  DoD,  National  Aeronautics  and  Space 
Administration  (NASA) ,  and  the  Intelligence  communities  and  that 
enable  independent  and  interoperable  connectivity  through  the 
coordinated  mandate  of  standards,  jointly  controlled  interfaces, 
and  protocols. 

The  Transformational  Communications  Architecture  (TCA) 
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Baseline  Version  2.0  document  represents  the  culmination  of  over 
eighteen  months  of  work  focused  on  evolving  the  TCA  from  a 
concept  into  a  series  of  executable  programs  that  will  connect 
the  DoD,  NASA,  and  the  Intelligence  communities.  The  TCA 
Baseline  Version  2.0  document  provides  a  technical  foundation  for 
enabling  and  guiding  development  of  U.S.  Government 
communications  capabilities  for  the  next  two  decades. 

6. 1.6. 2. 2  Joint  Tactical  Radio  System  (JTRS)  Software 
Compliant  Architecture  (SCA) 

In  March  2005,  the  Under  Secretary  of  Defense  of 
Acquisition,  Technology,  and  Logistics  (USD  AT&L)  appointed  a 
Joint  Program  Executive  Officer  (JPEO)  for  JTRS  to  provide  an 
overarching  management  structure.  The  JPEO  JTRS  was  given  full 
directive  authority  for  all  waveform,  radio,  and  common  ancillary 
equipment  development;  performance  and  design  specifications; 
standards  for  operation  of  the  system;  and  JTRS  systems 
engineering.  In  addition,  the  JPEO  JTRS  is  responsible  for 
conducting  cost,  schedule,  and  performance  evaluations  for  all 
JTRS  activities  as  well  as  a  comprehensive  review  of  the  JTRS 
organization . 

Since  its  inception,  the  JPEO  JTRS  has  taken  many  key 
actions  to  accomplish  its  directive,  including  in-depth 
assessments  of  the  various  Program  Management  Offices,  the 
creation  of  a  Systems  Engineering  Council  to  assess  and  implement 
common  solutions  across  programs,  and  the  realignment  of  JTRS 
functions  to  improve  overall  efficiency  and  effectiveness.  At 
each  milestone,  senior  leadership  was  engaged  to  ensure 
concurrence  on  the  program's  continued  progress.  Additionally, 
the  JPEO  JTRS  office  developed  an  overarching  systems  engineering 
approach  and  an  open  JTRS  technology  base  to  strengthen 
interoperability,  affordability,  and  speed  to  capability  to 
counter  requirements  growth. 

The  SCA  plays  a  vital  role  within  the  JPEO  JTRS  program  by 
standardizing  the  deployment,  management,  interconnection,  and 
intercommunication  of  software  application  components  in 
embedded,  distributed-computing  communication  systems.  While  the 
SCA  is  published  and  maintained  by  the  JPEO  JTRS,  it  has  received 
wide  support  and  use  from  commercial  radio  developers  and 
industry  organizations.  The  JPEO  JTRS  remains  the  sole 
certification  authority  for  the  SCA. 

6. 1.6. 2. 3  Teleports 

DoD  Teleports  will  provide  the  warfighter  net-centric 
internet  protocol  (IP)  access  to  the  Global  Information  Grid 
(GIG) .  The  DoD  Teleport  architecture  is  an  environment  that 


6-12 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


provides  deployed  forces  with  sufficient  interfaces  for  multi¬ 
band  and  multi-media  connectivity  from  worldwide  locations  to 
Defense  Information  System  Network  (DISN)  Service  Delivery  Nodes 
(SDN)  and  tactical  command,  control,  communications,  computers, 
and  intelligence  (C4I)  systems.  This  system  will  facilitate  the 
interoperability  between  multiple  Satellite  Communications 
(SATCOM)  systems  and  deployed  tactical  networks,  thus  providing 
the  user  a  seamless  interface  into  the  DISN  and  C4I  systems. 

6. 1.6. 2. 4  Joint  Battle  Management  Command  and  Control 

( JBMC2 ) 


The  JBMC2  roadmap  defines  the  long-range  goals  for  JBMC2 
and  the  Joint  and  Services'  programs  that  support  those  goals. 
JBMC2  is  a  construct  that  consists  of  the  processes, 
architectures,  systems,  standards,  and  command  and  control 
operational  concepts  employed  by  the  Joint  Force  Commander  during 
the  planning,  coordination,  directing,  controlling,  and  assessing 
of  Joint  force  operations  from  interface  with  strategic  level 
through  the  tactical  level. 

6. 1.6. 3  System  of  Systems  (SoS)  or  Family  of  Systems  (FoS) 
Integration  and  Interoperability  Validation 

6. 1.6. 3.1  FORCEnet  Integrated  Management  Plan 

An  integrated  Navy/Marine  Corps  FORCEnet  integration  and 
interoperability  management  plan  has  been  developed  jointly  by 
COMSPAWARSYSCOM  (FORCEnet  CHENG)  and  MARCORSYSCOM  in  coordination 
with  DASN (RDT&E)  CHSENG  to  refine  and  integrate  the  tools  and 
processes  for  program  assessment  and  data  management  and  address 
configuration  management  and  execution  phase  governance.  The 
plan  will  define  the  process  for  SoS  or  FoS  engineering  and 
interoperability  validation. 

DASN (RDT&E)  CHSENG  will  work  with  DON  Chief  Information 
Officer  (CIO),  Deputy  DON  CIO  (Navy),  PEO(EIS),  and  Naval  Network 
Warfare  Command  (NETWARCOM)  to  incorporate  the  business  domain 
into  the  FORCEnet  integrated  architecture  and  to  integrate 
business  and  warfighting  IT  acquisition  processes  and  databases. 

6. 1.6. 3. 2  FORCEnet  Efficiency  and  Effectiveness 

FORCEnet  implementation  will  require  efficient  and 
effective  processes  and  practices.  Unnecessarily  redundant 
processes  and  practices  should  be  eliminated.  FORCEnet 
implementation  should  use  existing  processes  wherever  feasible 
and  should  employ  efficient  information  management  strategies  and 
practices,  including  the  "enter  once  use  often"  strategy  for 
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databases.  Implementation  managers  should  take  advantage  of  the 
DASN (RDT&E)  CHSENG  naval  collaborative  engineering  environment, 
which  offers  common  processes,  practices,  procedures,  databases, 
and  products. 

6. 1.6. 3. 3  Roles  and  Responsibilities  for  FORCEnet 
Implementation  Within  the  Acquisition  Community 

Commander,  Naval  Network  Warfare  Command  (NETWARCOM)  and 
Commanding  General,  Marine  Corps  Combat  Development  Command 
(MCCDC)  have  the  lead  in  developing  the  operational  views  (OVs) . 
DASN (RDT&E)  chief  systems  engineer  (CHSENG)  will  oversee 
development  of  FORCEnet  integrated  architecture  system  views  and 
technical  views  (SVs  and  TVs)  through  the  architecture  governance 
process.  The  responsibilities  of  the  COMSPAWARSYSCOM  (FORCEnet 
CHENG)  and  other  members  of  the  DON  acquisition  community  for 
developing  system  views  (SVs)  and  technical  views  (TVs)  are 
included  in  the  below  roles  and  responsibility  statements  per 
ASN (RD&A)  memorandum  of  14  Jul  2005. 

a.  Assistant  Secretary  of  the  Navy,  Research, 

Development,  and  Acquisition  (ASN (RD&A)) 

(1)  Provides  overall  guidance  and  direction  for  the 
Department  of  the  Navy  (DON)  acquisition  community's 
participation  in  the  FORCEnet  implementation  process. 

(2)  Resolves  system  integration  issues  that  cannot  be 
resolved  at  a  lower  level. 

(3)  As  Component  Acquisition  Executive,  ensures 
compliance  with  FORCEnet  policies,  architecture,  and  standards 
during  program  reviews  and  milestone  decisions. 

(4)  Coordinates  with  the  Chief  of  Naval  Operations 
(OPNAV)  and  Headquarters  Marine  Corps  (HQMC)  resource  and  warfare 
sponsors  to  address  any  cost,  performance,  or  schedule  impacts 
associated  with  modifying  legacy  systems  to  comply  with  FORCEnet 
standards . 


(5)  Coordinates  with  OPNAV  and  HQMC  to  identify 
funding  for  FORCEnet  implementation. 

(6)  Coordinates  with  Department  of  the  Navy  (DON) 
Chief  Information  Officer  (CIO)  to  ensure  compliance  with  DON 
information  management  and  information  technology  (IT)  policies. 

(7)  Coordinates  with  OPNAV,  MCCDC,  and  Fleet  Forces 
Command  N6/NETWARCOM  to  designate  legacy  programs  as  FORCEnet 
programs . 
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b.  Deputy  Assistant  Secretary  of  the  Navy  (Research, 
Development,  Test  and  Evaluation) ,  Chief  Systems  Engineer 
(DASN (RDT&E)  CHSENG) 

(1)  Oversees  the  development  of  the  FORCEnet 
integrated  architecture  SVs  and  TVs  through  the  architecture 
governance  process. 

(2)  Advises  ASN (RD&A)  on  the  resolution  of  cross¬ 
systems  command  (SYSCOM)  integration  issues. 

(3)  In  coordination  with  appropriate  Deputy  Assistant 
Secretaries  of  the  Navy  (DASNs) ,  facilitates  resolution  of  cross¬ 
service  and  cross-agency  technical  interoperability  issues  with 
counterpart  service  and  agency  acquisition  executives. 

(4)  Facilitates  development  of  a  FORCEnet  integration 
and  interoperability  management  plan.  Ensures  coordination  of 
the  plan  with  related  initiatives,  including  the  Program 
Executive  Officer  for  Integrated  Warfare  Systems  (PEO  (IWS))-led 
Open  Architecture  initiative  and  the  PEO  for  Command,  Control, 
Communications,  Computers,  Intelligence  and  Space  (PEO  (C4I  and 
Space) ) -led  Net-Centric  Enterprise  Solutions  for  Interoperability 
(NESI)  initiative. 

(5)  Coordinates  and  oversees  the  implementation  of 
this  policy,  and  makes  revision  recommendations  to  ASN (RD&A) . 

(6)  Provides  Naval  representatives  to  the  Global 
Information  Grid  Technical  Guidance  (GTG) ,  which  now  included  the 
Department  of  Defense  (DoD)  IT  Standards  Registry  (DISR) ,  IT 
Standards  Working  Groups  to  ensure  that  both  mandated  and 
emerging  FORCEnet  and  joint  standards  are  included  in  the  GTG. 

c.  Commander,  Space  and  Naval  Warfare  Systems  Command 
(COMSPAWARSYSCOM)  (FORCEnet /Command,  Control,  Communications, 
Computers,  Intelligence  (C4I)  Chief  Engineer  (CHENG)) 

(1)  Provides  overall  technical  guidance  and  advice 
for  implementing  FORCEnet. 

(2)  Leads  the  development  of  the  enterprise-wide 
FORCEnet  integrated  architecture  SVs  and  TVs  in  coordination  with 
MARCORSYSCOM,  and  ensures  integration  with  the  NETWARCOM  and 
MCCDC-developed  OVs .  Provides  guidance  and  support  to  programs 
in  their  development  of  program  specific  SVs  and  TVs  and  ensures 
they  are  consistent  with  the  overarching  views.  Works  with  PEO 
(IWS)  and  the  Open  Architecture  Enterprise  Team  (OAET)  to 
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coordinate  FORCEnet  architecture  development  and  Naval  Open 
Architecture  efforts.  When  directed,  coordinates  with  the 
DASN (RDT&E)  CHSENG,  program  executive  officer  for  information 
technology  (PEO  (IT)),  direct  reporting  program  manager  (DRPM) 
NMCI,  DON  CIO,  and  Deputy  DON  CIO  (Navy)  for  integration  of 
business  IT  architecture  and  standards  with  the  FORCEnet 
integrated  architecture  and  standards. 

(3)  In  collaboration  with  DASN (RDT&E)  CHSENG,  Marine 
Corps  Systems  Command  (MARCORSYSCOM) ,  and  other  stakeholders, 
develops  and  manages  the  FORCEnet  compliance  process  and 
associated  processes,  ensuring  efficiency,  effectiveness,  and 
minimal  additional  workload  on  program  managers. 

(4)  Leads  the  FORCEnet/C4I  Virtual  SYSCOM,  and 
coordinates  efforts  with  the  other  Virtual  SYSCOMs . 

(5)  Participates  with  MARCORSYSCOM  under  DASN (RDT&E) 
CHSENG  oversight  in  the  development  of  a  FORCEnet  integration  and 
interoperability  management  plan. 

(6)  Leads  the  integration  and  interoperability 
validation  of  FORCEnet  FoS . 

(7)  Coordinates  acquisition  community  participation 
in  FORCEnet  experimentation  with  other  acquisition  community 
participants,  NETWARCOM,  and  MCCDC. 

(8)  Collaborates  with  NETWARCOM  and  other 
stakeholders  to  ensure  that  the  FORCEnet  integrated  architecture 
is  properly  integrated  with  the  GIG  integrated  architecture  and 
approved  multinational  information  sharing  architectures. 

(9)  Leads  FORCEnet  industry  outreach  and 
participation  in  industry  standards  forums. 

(10)  Serves  as  FORCEnet  Technical  Authority  (TA)  per 
reference  (i) . 

(11)  Guides,  supports,  and  oversees  FORCEnet  testing 
and  certification  of  individual  systems  as  compliant  with 
applicable  FORCEnet  technical  standards. 

(12)  Coordinates  development  of  common  data  reference 
models  per  the  DoD  Data  Management  Strategy. 
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d.  Commander,  Space  and  Naval  Warfare  Systems  Command 
(COMSPAWARSYSCOM)  (roles  and  responsibilities  as  SYSCOM  commander 
in  addition  to  COMSPAWARSYSCOM  (FORCEnet  CHENG)  roles  and 
responsibilities  defined  above) 

(1)  Guides,  supports,  and  oversees  FORCEnet 
implementation  in  SPAWARSYSCOM  systems. 

(2)  Participates  in  integration  and  interoperability 
validation  of  FORCEnet  FoS  involving  SPAWARSYSCOM  systems. 

(3)  Provides  FORCEnet  integration  and 
interoperability  support  for  SPAWARSYSCOM  systems. 

e.  Commander,  Naval  Air  Systems  Command  (COMNAVAIRSYSCOM) 

(1)  Per  COMSPAWARSYSCOM  (FORCEnet  CHENG)  guidance, 
supports  and  oversees  FORCEnet  implementation  in  NAVAIRSYSCOM 
systems . 

(2)  Participates  in  the  development  of  the  FORCEnet 
integrated  architecture  SVs  and  TVs  to  ensure  appropriate 
representation  of  NAVAIRSYSCOM  systems  and  Sea  Strike 
capabilities . 

(3)  Supports  integration  and  interoperability 
validation  of  FORCEnet  FoS  involving  NAVAIRSYSCOM  systems. 

(4)  Provides  FORCEnet  integration  and 
interoperability  support  for  NAVAIRSYSCOM  systems. 

f.  Commander,  Naval  Sea  Systems  Command  (COMNAVSEASYSCOM) 

(1)  Per  COMSPAWARSYSCOM  (FORCEnet  CHENG)  guidance, 
supports  and  oversees  FORCEnet  implementation  in  NAVSEASYSCOM 
systems . 

(2)  Participates  in  the  development  of  the  FORCEnet 
integrated  architecture  SVs  and  TVs  to  ensure  appropriate 
representation  of  NAVSEASYSCOM  systems  and  Sea  Shield  and  Sea 
Basing  capabilities. 

(3)  Supports  integration  and  interoperability 
validation  of  FORCEnet  FoS  involving  NAVSEASYSCOM  systems. 

(4)  Provides  FORCEnet  integration  and 
interoperability  support  for  NAVSEASYSCOM  systems. 
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g.  Commander,  Marine  Corps  Systems  Command 
( COMMARCORS YSCOM) 

(1)  Per  COMSPAWARS YSCOM  (FORCEnet  CHENG)  guidance, 
supports  and  oversees  FORCEnet  implementation  in  MARCORSYSCOM 
systems . 

(2)  Participates  in  the  development  of  the  FORCEnet 
integrated  architecture  SVs  and  TVs  to  ensure  appropriate 
representation  of  MARCORSYSCOM  systems  and  Expeditionary  Warfare 
and  Sea  Basing  capabilities. 

(3)  Supports  integration  and  interoperability 
validation  of  FORCEnet  SoS  or  FoS  involving  MARCORSYSCOM  systems. 

(4)  Through  the  Deputy  Commander  for  C4I  Integration, 
ensures  that  reference  (j)  is  aligned  with  the  FORCEnet 
management  process;  collaborates  with  COMSPAWARSYSCOM  (FORCEnet 
CHENG)  under  DASN (RDT&E)  CHSENG  oversight  to  develop  a  FORCEnet 
integration  and  interoperability  management  plan. 

(5)  Provides  FORCEnet  integration  and 
interoperability  support  for  MARCORSYSCOM  systems. 

h.  Program  Deputy  Assistant  Secretaries  of  the  Navy 

(DASNs) 


Oversee  FORCEnet  compliance  of  programs  under  their 
purview,  and  advise  ASN (RD&A)  on  the  resolution  of  architecture, 
standards,  and  system  integration  issues. 

i.  Program  Executive  Officers  (PEOs) ,  Direct  Reporting 
Program  Managers  (DRPMs) ,  and  Program  Managers  (PMs)  of  FORCEnet 
Programs 


(1)  Bring  programs  into  compliance  with  funded 
FORCEnet  requirements,  as  defined  in  revised  capability 
documents,  and  with  the  applicable  FORCEnet  technical  standards. 

(2)  Provide  and  update  data  to  the  databases  and 
toolsets  approved  by  the  COMSPAWARSYSCOM  (FORCEnet  CHENG)  and 
participate  in  program  assessments. 

(3)  Develop  program  specific  SVs  and  TVs  and  ensure 
they  are  consistent  with  the  overarching  FORCEnet  views  in  the 
Integrated  Architecture. 

(4)  Address  FORCEnet  compliance  in  program  cost 
estimates  and  within  the  Planning,  Programming,  Budgeting,  and 
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Execution  (PPBE)  process;  work  with  the  program  and  resource 
sponsors  and  the  COMSPAWARSYSCOM  (FORCEnet  CHENG)  to  agree  on  the 
applicable  FORCEnet  capabilities  and  technical  standards  in 
consideration  of  available  funding  and  effect  on  program  cost, 
performance,  and  schedule  of  any  system  modifications  required. 

(5)  Participate  in  the  integration  and 
interoperability  validation  of  FORCEnet  FoS  under  their  purview, 
including  participation  in  System  Engineering  Integrated  Product 
Team  (SE  IPTs)  and  development  of  applicable  system  performance 
specifications . 

(6)  Consistent  with  program  and  resource  sponsor 
guidance  and  the  Navy  Comptroller  rules  for  proper  use  of  various 
appropriations,  use  system  capability  improvement  and  maintenance 
funding  as  an  opportunity  to  enhance  compliance  with  FORCEnet 
technical  standards. 

(7)  Report  the  status  of  FORCEnet  compliance  at  each 
milestone  and  program  review. 

(8)  Comply  with  the  information  security 
certification  requirements  of  reference  (k) . 

j .  Program  Executive  Officer  for  Integrated  Warfare 
Systems  (PEO  (IWS) ) 

Coordinates  Naval  Open  Architecture  efforts  with 
FORCEnet  implementation. 

k.  DON  Milestone  Decision  Authorities  (MDAs) 

Ensure  compliance  with  FORCEnet  policies  and 
integrated  architecture  during  program  reviews  and  milestone 
decisions . 

6. 1.6. 4  Interoperability  and  Integration  Support 

Per  reference  (a) ,  system  design  shall  take  into  account 
potential  international  program  ramifications  as  an  integral  part 
of  the  design  process.  For  international  cooperative  programs, 
these  design  considerations  are  mandatory.  For  U.S.-only 
development  efforts,  the  PM  shall  consider  designing  the  proposed 
system  with  a  potential  for  eventual  international  sales  and 
support . 

6. 1.6. 5  Facilities  and  Infrastructure 
6.1.7  Survivability 
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See  reference  (a)  for  guidance  and  direction. 

6.1.8  Shipboard  Systems  Integration 

A  ship  System  Design  Specification  will  include  interface 
definitions  and  interoperability  characteristics.  Integrated 
topside  design,  which  is  part  of  the  ship  systems  engineering 
process,  is  a  key  activity  for  maintaining  battle  force 
interoperability  and  mission  effectiveness.  A  systems 
engineering  process,  which  balances  the  competing  requirements 
posed  by  combat  capability,  ship  signatures,  global  connectivity, 
and  quality-of-life  solutions  must  be  applied  to  ship  design. 

The  intent  of  establishing  a  ship  System  Design  Specification 
within  the  context  of  the  total  ship  is  to  deliver  safe  and 
effective  topsides.  The  drivers  include: 

a.  Operability:  Ensure  that  sufficient  total  ship 
integration  has  occurred  to  provide  confidence  in  the  basic 
performance  of  the  ship  and  its  systems. 

b.  Interoperability:  Ensure  that  sufficient  cross¬ 
platform  integration  has  occurred  to  provide  confidence  in 
satisfactory  operation  of  the  ship  within  a  joint  battle  force. 

c.  Safety  and  Survivability:  Ensure  that  sufficient 
engineering  rigor  and  total  shipboard  systems  integration  have 
been  applied  to  provide  confidence  in  the  safety  and 
survivability  of  the  ship  and  its  personnel. 

Ship  PMs  should  facilitate  an  integrated  topside  design 
approach  in  both  ship  design  and  system  development.  Exercise 
discipline  in  technology  insertion  and  deployment  on  new  systems 
into  ships'  topsides  per  reference  (a) . 

Ship  PMs  shall  facilitate  lower  total  ownership  cost  (TOC) 
for  new  and  legacy  ships  per  reference  (a) .  Economic  advantages 
allow  pursuit  of: 

d.  Cost  Avoidance:  Comprehensive  topside  pre-planned 
product  improvement  (P3I)  strategies  enable  lowered  costs  of  ship 
upgrades  and  less  rework  cost.  Improved  practices,  materials, 
and  standards  (e.g.,  corrosion  control,  new  technology)  enable 
less  maintenance  workload. 

e.  Smaller  Fleet  Inventory:  A  constrained  number  of 
topside  systems,  shared  apertures  and  common  architecture  enable 
a  smaller  overall  piece-part  set  as  well  as  a  consolidated 
training  approach. 
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6.1.9  Performance  Specifications 

See  reference  (a)  for  guidance  and  direction.  For 
information  on  the  Data  Management  Strategy  see  updated  Defense 
Acquisition  Guidebook  (DAG),  chapter  2,  section  2.3.14.1,  and 
chapter  11,  Program  Management  Activities,  Integrated  Digital 
Environment . 

6. 1.9.1  System  Performance  for  SoS  and  FoS  Programs 

The  system  performance  specification  (SPS)  shall  serve  as 
the  basis  for  PMs  to  develop  or  modify  individual  systems 
specifications  under  their  cognizance  per  reference  (a) .  A  SoS 
or  FoS  SPS  shall  be  jointly  approved  by  the  respective  PMs  per 
reference  (a) .  After  Milestone  B,  or  Milestone  C  if  program 
initiation,  ASN (RD&A)  will  use  the  SPS  as  a  means  for  maintaining 
alignment  between  programs  during  execution  of  the  acquisition 
process . 


SoS/FoS  and  net-centric  considerations  are: 

a.  Competencies  needed  for  the  job/task,  ensuring  the 
skills  and  knowledge  requirements  are  within  the  human  capability 
domain  minimizing  problems  in  training  and  operation. 

b.  Designing  systems  with  summary  and  drill-down 
functionality,  providing  users  at  various  levels  of  access 
information  critical  to  their  assigned  jobs  e.g.  individual  and 
group  situational  awareness. 

c.  Complexities  in  a  knowledge  mapping  approach  - 
developing  an  adaptive  system  for  the  warfighter  with  an 
understanding  of  what  each  needs  to  know  to  perform  the  job/task, 
with  customized  individual  or  group  information  access  and 
representation . 

d.  Individual  and  group  integrated  web-based  tools. 
Authoring,  formatting,  decision-making  tools  for  individuals  and 
groups  that  facilitate  information  dissemination  and  absorption 
that  will  be  critical  to  ensure  the  Warfighter  is  not  overwhelmed 
with  the  information  and  publishing  process  itself. 

6. 1.9. 2  Standardization  and  Commonality 

See  reference  (a)  for  guidance  and  direction. 

6.1.10  Precise  Time  and  Time  Interval  (PTTI)  Support 

To  ensure  uniformity  in  precise  time  and  time  interval 
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operations.  Coordinated  Universal  Time  (UTC) ,  traceable  to 
UTC (USNO)  maintained  by  the  United  States  Naval  Observatory 
(USNO) ,  is  mandated  for  the  time  of  day  information  exchanged 
among  DoD  systems.  Traceability  to  UTC (USNO)  may  be  achieved  by 
various  means  depending  on  system  specific  accuracy  requirements. 

6.1.11  Geospatial  Information  and  Services  (GI&S) 

See  reference  (a)  for  guidance  and  support. 

6.1.12  Natural  Environmental  Support 

See  reference  (a)  for  guidance  and  support. 

6.1.13  Electromagnetic  Environmental  Effects  (E3)  and 
Spectrum  Supportability 

E3  on  equipment,  systems,  or  platforms  are  critical 
elements  that  must  be  considered  throughout  the  acquisition 
process  to  ensure  the  successful  operational  effectiveness  of 
these  military  assets  in  support  of  the  warfighter.  Reference 
(1)  contains  detailed  information  on  all  the  processes  and 
documents  used  by  the  Spectrum  Management  and  E3  communities  and 
should  be  consulted  for  additional  information.  For  information 
on  the  Life-Cycle  Signature  Support  Plan  see  DoD  Directive  5250.1 
and  CJCS  Instruction  3312. 01A.  Also  see  updated  Defense 
Acquisition  Guidebook  (DAG),  chapter  8,  Intelligence,  Counter 
Intelligence,  and  Security  Support.  For  specific  format 
information  call  the  Signature  Support  Program  at  877-238-8821  or 
see  on-line  contact  information  in  updated  DAG  chapter  8. 

6.1.14  Software 

6.1.15  Integrated  Product  and  Process  Development  (IPPD) 

PEOs,  SYSCOM  Commanders,  DRPMs,  and  PMs  should  ensure  the 
elements  of  IPPD  are  implemented  in  executing  all  programs  under 
their  cognizance.  See  the  Defense  Acquisition  Guidebook  for 
implementation  guidance  for  all  DON  ACAT  programs. 

6.1.15.1  Integrated  Product  Teams  (IPTs)  and  IPPD 

For  systems  being  designed  for  ships,  the  IPT  shall  make 
use  of  the  NAVSEA  shipboard  and  integrated  topside  design  (ITD) 
processes  for  the  integration  requirements  to  achieve  optimal 
product  performance  per  reference  (a) .  See  the  Defense 
Acquisition  Guidebook  for  implementation  requirements  for  all  DON 
programs . 
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6.1.15.2  Integrated  Technical  Information  Database 

PMs  should,  when  practicable,  develop  an  integrated 
technical  information  database  for  use  among  operational, 
maintenance,  logistics,  supply,  and  training  users.  This 
database  will  facilitate  the  sharing  of  design,  engineering, 
manufacturing,  production,  and  logistics  support  information 
thereby  reducing  duplication  and  life-cycle  support  costs.  This 
database  should  be  compatible  with  other  technical  information 
databases  of  programs  within  the  same  SoS  or  FoS .  The  Naval 
Safety  Center  maintains  a  mishap  database  that  may  be  used  in 
order  to  identify  safety  and  health  risks  associated  with  legacy 
systems . 

6.1.16  Modeling  and  Simulation  (M&S) 

See  the  Defense  Acquisition  Guidebook  for  implementation 
guidance  for  all  DON  programs. 

6.1.17  Software  Management 

The  milestone  decision  authority  (MDA)  should  provide 
specific  mandatory  software  management  implementation 
requirements  for  all  DON  ACAT  programs. 

6.1.18  Commercial -Of f-The-Shelf  (COTS)  Considerations 

Each  introduction  of  a  COTS-based  increment  of  capability, 
developed  under  an  evolutionary  acquisition  strategy,  should  be 
sustained  by  logistics  support  that  has  been  specifically 
tailored  to  meet  warfighter-specified  levels  of  performance  for 
that  increment.  Support-related  COTS  considerations  include  ease 
and  transparency  of  operation  and  maintenance,  safety,  security 
capabilities,  configuration  control  of  unique  aspects,  follow-on 
technology  infusion,  implications  for  human  systems  integration, 
adequacy  of  function  and/or  measurement  capability  for  the 
intended  application,  ability  of  the  Navy  maintenance 
infrastructure  or  contractor  support  to  properly  maintain  or 
calibrate  COTS  equipment  and  contribution  to  cost  effectiveness. 

Integration  of  COTS  items  into  a  system  can  cause 
unexpected  safety  hazards  and  ESOH  risks.  As  all  commercially 
available  items  are  not  necessarily  developed  to  the  same  safety 
standards  applied  in  the  DoD  acquisition  process,  there  is  an 
increased  potential  for  failures  that  can  result  in  system 
failures/losses  and  personnel  deaths/injuries.  The  PM  must 
address  the  COTS  items''  system  safety  and  software  engineering 
considerations  that  impact  procurement,  integration,  test,  and 
sustainment,  and  as  a  result  should  ensure  that  environment. 
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safety,  and  health-related  documentation  is  available  for 
assessing  potential  hazards  or  risks. 

6.1.19  Metric  System 

The  metric  system  of  measurement  is  the  preferred  system 
of  weights  and  measures  for  all  elements  of  defense  systems 
reguiring  new  design,  unless  the  PM  determines  that  it  is 
impractical  or  is  likely  to  cause  significant  inefficiencies  or 
loss  of  markets  to  United  States  firms  (15  U.S.C.  Sections  205a- 
205k  and  Executive  Order  12770)  .  Each  SYSCOM,  PEO,  and  DRPM  is 
responsible  for  administration  of  the  metrication  program. 

6.1.20  Value  Engineering 

Value  engineering  may  be  less  applicable  when  a  program  is 
using  COTS  hardware.  See  the  Defense  Acquisition  Guidebook  for 
implementation  guidance  for  all  DON  ACAT  programs. 

6.1.21  Accessibility  Requirements 

National  security  systems  as  defined  by  Section  5142  of 
the  Clinger-Cohen  Act  of  1996  (40  U.S.C.  Section  1452)  are  exempt 
from  the  accessibility  requirements  of  Section  508  of  the 
Rehabilitation  Act  of  1973  (see  29  U.S.C.  Section  794d(a) (5))  as 
amended  by  the  FY  2001  Appropriation  for  Military  Construction 
(see  Public  Law  106-246,  Section  2405,  of  July  13,  2000).  See 
the  Defense  Acquisition  Guidebook  for  accessibility  guidance  for 
all  other  DON  electronic  and  information  technology  programs. 

6.1.22  Government- Indus try  Data  Exchange  Program  (GIDEP) 

Reference  (m)  provides  specific  Navy  requirements  and 
procedures  for  participation  in  the  GIDEP  program. 

6 . 2  Human  Systems  Integration  (HSI) 

HSI  is  composed  of  the  systems  engineering  process  and 
program  management  efforts  that  provide  integrated  and 
comprehensive  analysis,  design  and  assessment  of  requirements, 
concepts,  and  resources  for  system  manpower,  personnel,  training, 
human  factors  engineering  (HFE) ,  personnel  survivability, 
habitability,  and  safety  and  occupational  health.  HSI  includes 
the  methods,  models,  hardware/sof tware  tools,  management  and 
operating  processes,  documentation,  system  design  features,  and 
data  for  integrating  the  human  into  the  system. 

The  goal  of  HSI  is  to  influence  materiel  solution 
analysis/technology  development,  system  design,  and  associated 
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support  requirements  so  that  developmental,  non-developmental , 
and  product-improved  systems  can  be  operated,  maintained, 
trained,  and  supported  in  the  most  optimized,  cost-effective  and 
safest  manner. 

HSI  is  based  on  seven  domains  that  are  intimately  and 
intricately  interrelated  and  interdependent  and  must  be  among  the 
primary  drivers  of  effective,  affordable,  and  safe  system 
designs.  HSI  integrates  and  facilitates  trade-offs  among  these 
eight  domains,  but  does  not  replace  individual  domain  activities, 
responsibilities,  or  reporting  channels.  HSI  domains  are 
described  as  follows. 

a.  Manpower.  The  numbers  of  personnel  (military, 
civilian  and  contractor)  required,  authorized  and  potentially 
available  to  operate,  maintain,  train,  administer,  and  support 
each  capability  and/or  system. 

b.  Personnel.  The  human  knowledge,  skills,  abilities, 
aptitudes,  competencies,  characteristics,  and  capabilities 
required  to  operate,  maintain,  train,  and  support  each  capability 
and/or  system  in  peacetime  and  war. 

c.  Training.  The  instruction,  education  and  resources 
required  to  provide  Navy  personnel  with  requisite  knowledge, 
skills,  and  abilities  to  properly  operate,  maintain,  train,  and 
support  Navy  capabilities  and/or  systems. 

d.  Human  Factors  Engineering.  The  comprehensive 
integration  of  human  characteristics  and  capabilities  and 
limitations  into  system  definition,  design,  development,  and 
evaluation  to  promote  effective  human-machine  integration  for 
optimal  total  system  performance. 

e.  Personnel  Survivability.  The  characteristics  of  a 
system  that  reduce  the  risk  of  fratricide  and  personal  detection 
or  targeting,  prevent  personal  attack  if  detected  or  targeted, 
increase  survival  and  prevent  injury  if  personally  attacked  or 
located  within  an  entity  being  attacked,  minimize  medical 
implications  if  wounded  or  otherwise  injured,  and  minimize 
physical  and  mental  fatigue. 

f.  Habitability.  System  characteristics  that  provide 
living  and  working  conditions  which  result  in  levels  of  personnel 
morale,  safety,  health,  and  comfort  adequate  to  sustain  maximum 
personnel  effectiveness  to  support  mission  performance  and  avoid 
personnel  retention  problems. 

g.  Safety  and  Occupational  Health.  Safety  is  the  systems 
engineering  process  involving  hazard  identification,  risk 
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evaluation,  design  analysis,  hazard  mitigation/control  and 
management.  The  process  manages  the  design  and  operational 
characteristics  of  a  system  that  eliminate  or  minimize  the 
possibilities  for  accidents  or  mishaps  caused  by  human  error  or 
system  failure. 

Occupational  health  is  the  systematic  application  of 
biomedical  knowledge,  early  in  the  acquisition  process,  to 
identify,  assess,  and  minimize  health  hazards  associated  with  the 
system's  operation,  maintenance,  repair,  or  storage. 

6.2.1  HSI  in  Acquisition 

HSI  is  initiated  early  in  the  acquisition  process  and 
implemented  as  described  in  the  acquisition  strategy.  Where  full 
capability  will  be  achieved  through  evolutionary  acquisition 
increments  or  pre-planned  product  improvement  modifications,  the 
long-term  strategy  for  achieving  HSI  requirements  within  each 
increment  or  modification  should  be  discussed  as  part  of  the 
overall  acquisition  strategy.  PMs  are  encouraged  to  coordinate 
with  CNO  (N12  and  N09FB)  on  the  development  of  the  HSI  approach 
for  each  increment  or  modification.  See  reference  (a)  for 
further  guidance  and  direction. 

6.2.2  Manpower,  Personnel,  and  Training  (MPT) 

MPT  concepts  should  be  consistent  with  the  Navy  Total 
Force  Strategy  as  described  in  reference  (n) . 

6. 2. 2.1  Manpower  and  Personnel 

Based  on  functional  analysis,  an  assessment  will  be 
conducted  to  determine  the  extent  to  which  functions  should  be 
automated,  eliminated,  consolidated,  or  simplified.  Manpower, 
personnel,  and  training  concepts  should  be  consistent  with  the 
Navy  Total  Force  Strategy  as  described  in  reference  (n) .  The  PM 
shall  take  advantage  of  other  system  and  mission  area  personnel 
initiatives  that  resulted  in  applicable  personnel  advantages  per 
reference  (o) . 

6. 2. 2. 2  Training 

The  Training  System  Plan  (TSP)  should  provide  manpower, 
personnel,  and  training  (MPT)  alternatives  in  support  of  the  ACAT 
program's  thresholds  and  objectives.  Individual  system  and 
platform  training  requirements  shall  be  developed  in  close 
collaboration  with  development  of  related  systems  throughout  the 
acquisition  process  to  increase  training  efficiency,  identify 
commonalities,  merge  training  requirements,  and  avoid  duplication 
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per  reference  (a)  . 

The  TSP  identifies  MPT  needs,  concepts,  strategies, 
constraints,  risks,  data,  resources,  and  also  guides  MPT  program 
and  budget  submissions.  References  (a)  and  (p)  for  Navy 
programs,  require  the  TSP.  The  resource  sponsor  approves  the 
TSP.  Navy  TSPs  are  approved  after  concurrence  by  CNO  (Nl) .  All 
programs  shall  develop  a  TSP.  An  initial  TSP  should  address  the 
MPT  concepts.  Development  of  the  TSP  is  the  responsibility  of 
the  PM.  CNO  (Nl)  shall  validate  functional  and/or  workload 
methodology  utilized  to  define  manpower  and  personnel 
requirements  contained  in  the  Navy  TSP  per  reference  (p) . 
Additional  guidance  on  the  Navy  TSP  can  be  found  in  reference  (p) 
and  accompanying  guides/manuals. 

Training  analyses  shall  be  conducted  as  part  of  the 
overall  systems  engineering  process  to  identify  options  for 
individual,  collective,  and  joint  training  for  operators, 
maintainers,  and  support  personnel,  and  to  identify  tasks  for 
training,  tasks  for  which  training  is  unnecessary  and  tasks  for 
which  Job  Performance  Aids  and  Electronic  Performance  Support 
Systems  can  maximize  task  efficiency  and  accuracy  per  references 
(p)  and  (q) .  In  addition,  the  analyses  shall  identify  tasks  for 
which  performance  should  be  designed  into  the  system  to  minimize 
the  amount  of  training  required,  minimize  task  overload  and 
maximize  efficiency  and  accuracy  of  the  performer  per  references 
(p)  and  (q) .  The  analyses  shall  review  processes  to  simplify 
tasks,  minimize  dependency  on  memory,  and  optimize  for  knowledge 
management  per  reference  (p) .  Training  decisions  shall  be  based 
on  the  results  of  front-end  and  media  analyses,  with 
consideration  given  to  the  types  of  knowledge  and  skills  to  be 
taught  and  the  application  of  instructional  design  principles  per 
reference  (p) .  Poor  design  and  un-mitigated  safety  hazards  are 
potential  contributors  to  increased  training  requirements  and 
costs.  These  can  be  minimized  through  early  planning  and 
integration  with  HFE  and  system  safety. 

6.2.3  Human  Factors  Engineering  (HFE) 

The  purpose  of  HFE  is  to  achieve  system  performance,  MPT, 
maintenance,  and  habitability  requirements,  as  well  as  mitigate 
safety  and  health  hazard  issues.  It  shall  encompass  functional 
analysis  and  allocation  of  functions  and  technology  requirements 
to  support  functional  allocation  concepts,  and  M&S  to  further 
develop  and  evaluate  alternative  concepts  for  addressing  human 
roles,  responsibilities  and  requirements  in  system  performance 
per  reference  (a) .  An  acquisition,  design,  or  development 
approach  shall  consider  system  integration  as  one  of  the  initial 
steps  in  design  per  reference  (a) .  Human  involvement  should  be 
justified  through  a  function  and  task  analysis  that  can  be  used 
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as  a  basis  to  make  human-machine  allocation  decisions.  The  goal 
is  to  reduce/eliminate  redundancy,  optimize  task  allocation  and 
information  flow,  and  ensure  an  efficient  and  cost-effective 
process  throughout  the  system.  The  HFE  considerations  for  system 
design  will  extend  to  job  procedures,  job  aids,  and  decision 
support  systems.  The  HFE  effort  will  also  emphasize  design 
activities  required  to  ensure  quality  of  service,  including 
quality  of  life  and  quality  of  work.  Opportunities  for  cost 
savings  and  mission  enhancement  include  materials  handling, 
maintenance  functions,  human,  sensor,  and  computer  interface, 
walking  and  working  surfaces  (safety) ,  and  design  for  most 
efficient  access.  The  design  should  minimize  human  performance 
errors,  interface  problems,  and  workload  (physical,  cognitive, 
attention)  requirements.  CNO  (N15)  should  consult  with  CNO 
(N09FB)  for  areas  related  to  human  factors  engineering  and 
ergonomics  per  OPNAVINST  5450. 180D.  CNO  (N09FB) ,  Commander  Naval 
Installations  Command  (CNIC) ,  Naval  Facilities  Engineering 
Command  (NAVFACENGCOM) ,  and  Bureau  of  Naval  Medicine  (BUMED) 
ergonomic  experts  may  be  consulted  on  ergonomic  and  safety 
measures  to  reduce  manpower  and  human  factors  risks. 

6.2.4  Personnel  Survivability 

Waivers  that  affect  health  and  safety  should  be  reviewed 
by  a  system  safety  process  per  reference  (q)  and  evaluated  at  a 
management  level  consistent  with  the  risk.  CNO  (N15)  should 
consult  with  SYSCOM  technical  authorities  for  survivability  and 
their  resource  sponsors  for  guidance  affecting  their  areas  of 
responsibility . 

6.2.5  Habitability 

CNO  (N15)  should  consult  with  SYSCOM  technical 
authorities  for  habitability  and  their  resource  sponsors  for 
guidance  affecting  their  areas  of  responsibility.  See  reference 
(a)  for  further  guidance. 

6 . 3  Environment,  Safety,  and  Occupational  Health  (ESOH) 

ASN(EI&E)  advises  ASN (RD&A)  on  ESOH  issues,  to  include 
review  and  comment  on  or  endorsement  of  National  Environmental 
Policy  Act  (NEPA)  or  Executive  Order  (EO)  12114  environmental 
documents  (see  the  tables  in  reference  (a)  )  . 

Balancing  the  elimination  or  reduction  of  ESOH  hazards  and 
associated  risk  with  an  informed  and  structured  residual  risk 
acceptance  process  is  essential  for  positively  contributing  to  a 
program's  efforts  in  meeting  cost,  schedule,  and  performance 
requirements.  ESOH  risks  are  part  of  each  program's  overall 
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cost,  schedule,  and  performance  risks  and  the  program  should 
review  them  from  within  that  overall  context.  The  ESOH  risk 
management  process  uses  ESOH  risk  analysis  matrices,  based  on  the 
guidance  in  MIL-STD-882D.  The  risk  matrices  should  use  clearly 
defined  probability  and  severity  criteria  (either  qualitative  or 
quantitative)  to  categorize  ESOH  risks.  PMs  elect  to  either 
establish  a  single  consolidated  ESOH  risk  matrix  or  use 
individual  environmental,  safety,  and  occupational  health 
matrices . 

The  three  basic  types  of  ESOH  risks  are: 

a.  Potential  ESOH  impacts  and  adverse  effects  from 
routine  system  development,  testing,  training,  operation, 
sustainment,  maintenance,  and  demilitarization/disposal. 

b.  Potential  ESOH  and  mission  readiness  impacts  from 
system  failures  or  mishaps,  including  critical  software  failures. 

c.  Potential  impacts  to  program  life-cycle  cost, 
schedule,  and  performance  from  ESOH  compliance  requirements. 

Safety  consists  of  those  system  design  characteristics 
that  serve  to  minimize  the  potential  for  mishaps  causing  death  or 
injury  to  operators  and  maintainers  or  threaten  the  survival 
and/or  operation  of  the  system.  Prevalent  issues  include  factors 
that  threaten  the  safe  operation  and/or  survival  of  the  platform, 
control  of  hazardous  energy  release-mechanical,  electrical, 
fluids  under  pressure,  ionizing  and  non-ionizing  radiation  (often 
referred  to  as  "lock-out/tag-out"),  walking  and  working  surfaces 
including  work  at  heights,  fire  and  explosion  and  pressure 
extremes . 

System  safety  analyses  should  address  hardware,  software, 
and  people  as  appropriate  from  design  through  operation, 
sustainment,  and  disposal.  System  safety  tools  will  also  be  used 
to  qualify  and  quantify  environmental  protection  risks  and 
results  of  such  ESOH  analyses  and  residual  risk  acceptance  should 
be  summarized  in  the  programmatic  ESOH  evaluation  (PESHE) . 

Occupational  health  hazards  are  system  design  features 
that  create  risks  of  injury,  acute  or  chronic  illness, 
disability,  and/or  reduce  job  performance  of  personnel  who 
operate,  maintain,  or  support  the  system.  Prevalent  issues 
include  acoustic  energy  (noise) ,  biological  substances,  chemical 
safety,  atmospheric  hazards  (including  those  associated  with 
confined  space  entry  and  oxygen  deficiency) ,  shock  and  vibration, 
ionizing  and  non-ionizing  radiation,  human  factors  issues  that 
can  create  chronic  disease  and  discomfort  such  as  repetitive 
motion  diseases  and  temperature  extremes.  Many  occupational 
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health  problems,  particularly  noise  and  chemical  substance 
management,  overlap  with  environmental  impacts.  Human  factors 
stresses  that  create  risk  of  chronic  disease  and  discomfort 
overlap  with  HSI  and  HFE  considerations.  The  PESHE  describes  how 
ESOH  risks  are  managed,  how  ESOH  and  HSI  efforts  are  integrated, 
and  summarizes  the  ESOH  risk  information  (hazard  identification, 
risk  assessment,  mitigation  decisions,  residual  risk  acceptance, 
and  evaluation  of  mitigation  effectiveness) . 

There  is  no  specific  format  for  the  PESHE.  The  PM 
documents  the  PESHE  in  whatever  manner  is  most  useful  to  the 
program  and  best  communicates  to  decision  makers  ESOH  issues 
affecting  the  program.  The  PESHE  also  summarizes  the  ESOH  of  the 
system,  discusses  the  approach  for  integrating  ESOH 
considerations  into  the  systems  engineering  process,  identifies 
ESOH  responsibilities,  provides  a  method  for  tracking  progress, 
and  includes  a  schedule  for  NEPA  and  EO  12114  compliance.  During 
system  design,  the  PM  documents  hazardous  material  used  in  the 
system  and  plans  for  the  system's  demilitarization  and  disposal. 
The  PESHE  is  required  for  all  programs,  regardless  of  ACAT . 

Prior  to  submittal,  CNO  N45  and  CNO  N009FB  should  review  the 
PESHE.  The  PESHE  is  required  at  Program  Initiation  for  ships. 
Milestone  B  (for  all  programs)  with  an  update  for  MS  C  and  Full- 
Rate  Production  Decision  Review.  Development  of  the  PESHE  is  the 
responsibility  of  the  PM.  Additional  guidance  on  the  PESHE  can 
be  found  in  the  Defense  Acquisition  Guidebook. 

Reference  (q)  does  not  require  that  the  PESHE  supersede  or 
replace  other  ESOH  plans,  analyses,  and  reports  (e.g..  System 
Safety  Management  Plan/Assessments,  Hazardous  Material  (HAZMAT) 
Management  Plan,  Pollution  Prevention  Plan,  Health  Hazard 
Assessments,  etc.);  the  PM  incorporates  the  information  provided 
by  these  documents  by  reference,  as  appropriate.  However,  to  the 
maximum  extent  possible,  the  PM  should  minimize  duplication  of 
effort  and  documentation  and  give  preference  to  recording  ESOH 
information  in  the  PESHE,  as  opposed  to  maintaining  a  series  of 
overlapping,  redundant  documents.  HSI  also  addresses  many  of  the 
safety  and  health  ESOH  areas.  The  PESHE  describes  the  linkage 
between  ESOH  and  HSI  and  how  the  program  avoids  duplication  of 
effort . 

6.3.1  ESOH  Compliance 

See  reference  (a)  for  guidance  and  direction. 

6.3.2  National  Environmental  Policy  Act  (NEPA)  and  Executive 
Order  (EO)  12114  Environmental  Effects  Abroad 

The  NEPA  and  EO  12114  compliance  schedule  includes  events 
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or  proposed  actions  (such  as  T&E,  fielding/basing  activities,  and 
disposal  actions)  throughout  the  program's  life-cycle.  The 
proponent  for  each  proposed  action  having  the  lead  to  prepare  the 
formal  NEPA  documentation,  establishes  the  initiation  date  for 
each  action,  establishes  the  type  of  NEPA/EO  12114  documentation 
prior  to  the  proposed  action  start  date,  establishes  the  start 
and  completion  dates  for  the  final  NEPA/EO  12114  documentation, 
and  identifies  the  specific  approval  authority. 

The  PEO,  SYSCOM  Commander,  DRPM,  PM,  designees,  and  other 
action  proponents  as  listed  in  reference  (a)  are  responsible  for 
environmental  planning,  budgeting,  and  compliance  with 
environmental  requirements  for  DON  acquisition  and  non¬ 
acquisition  programs. 

Preparation  of  applicable  NEPA  and  EO  12114  documentation 
is  considered  an  integral  part  of  planning  for  testing, 
production,  and  deployment.  Environmental  planning  process 
should  be  initiated  at  the  outset  of  new  program  planning. 

Action  proponents  shall  consider  and  document  the  potential  to 
affect  the  human  and  natural  environment  before  decisions  that 
could  affect  the  human  and  natural  environment  are  made  per 
reference  (a) .  As  part  of  NEPA  process,  alternatives  must  be 
considered  including  alternative  sites.  Reference  (r)  provides 
DON  policy  for  selecting  sites  per  NEPA  and  EO  12114. 

6.3.3  Safety  and  Health 

CNO  (N15)  should  consult  with  CNO  (N09FB)  for  areas 
related  to  safety  per  OPNAVINST  5450. 180D.  CNO  (N09FB) ,  Naval 
Facilities  Engineering  Command  (NAVFAC) ,  and  Bureau  of  Naval 
Medicine  (BUMED)  ergonomic  experts  may  be  consulted  on  ergonomic 
and  safety  measures  to  reduce  manpower  and  human  factors  risks. 
See  references  (a),  (s) ,  and  (t)  for  further  guidance. 

6.3.4  Hazardous  Materials  (HAZMAT)  Management 

Per  reference  (u) ,  a  hazardous  material  is  defined  as 
anything  that,  because  of  its  quantity,  concentration,  or 
chemical,  biological,  or  physical  characteristics,  may  pose 
substantial  hazard  to  human  health  of  the  environment  and 
generate  ESOH-related  concerns  that  result  in  an  elevated  level 
of  effort  to  manage.  This  definition  includes  materials  that  may 
be  used  in  manufacturing,  operations,  maintenance,  and  disposal 
over  a  system's  life-cycle,  which  may  result  in  the  release  of 
hazardous  materials. 

Hazardous  materials  management  includes  maintaining  the 
following  risk  information:  locations  and  quantities  of 
hazardous  material  in  the  system,  energetic  qualification 
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information  for  each  energetic  material  used  in  the  system, 
reasonably  anticipated  hazardous  byproducts/discharges  and 
expected  quantities  of  hazardous  waste  generated  during  normal 
use/maintenance  as  well  as  during  emergency  situations,  special 
hazardous  material  training  and  handling  requirements,  and 
demilitarization  and  disposal  requirements.  The  preferred 
mitigation  strategy  is  source  reduction  or  elimination  of  the 
hazards,  also  referred  to  as  pollution  prevention.  References 
(v)  and  (w)  set  forth  policy  and  uniform  procedures  for 
demilitarization  and  disposal  of  DoD  property.  Authorization  for 
Navy  and  Marine  Corps  possession  and  use  of  radioactive  material 
is  granted  by  Naval  Radioactive  Material  Permits  issued  by  the 
Naval  Radiation  Safety  Committee.  Products  used  in  maintenance  of 
weapons  systems  and  related  support  equipment  and  facilities 
account  for  approximately  80  percent  of  the  hazardous  materials 
and  related  waste  generated  by  DoD.  Thus,  design  for  use  of  the 
least  hazardous  materials  and  process  consistent  with  efficiency 
and  mission  performance  provides  enormous  opportunities  for  risk 
management  and  life  cycle  cost  avoidance. 

The  acquisition  of  ozone  depleting  substances  is 
prohibited  unless  authorized  per  Public  Law  102-484  of  23  Oct  92 
(National  Defense  Authorization  Act  for  Fiscal  Year  1993)  Section 
312;  EO  13423  of  24  Jan  07;  SECNAV  memorandum  of  28  May  93, 
Elimination  of  Class  I  Ozone  Depleting  Substances  in  Department 
of  Navy  Contracts;  Navy  Marine  Corps  Acquisition  Regulation 
Supplement  (NMCARS)  Subpart  5223.8;  ASN (RD&A)  memorandum  of  12 
Nov  97,  Equipment /Systems  Requiring  the  Unplanned  Use  of  Class  I 
Ozone-Depleting  Substances;  and  all  implementing  procurement 
regulations . 

6.3.5  Pollution  Prevention 

The  PM  should  consider  pollution  prevention  methods, 
practices,  and  technologies  early  in  the  program  to  mitigate 
ESOH,  cost,  and  schedule  risks.  Pollution  prevention  should  be 
an  integral  part  of  systems  engineering  throughout  the  life-cycle 
of  the  program. 

The  DoD  Green  Procurement  Program  (GPP)  applies  to  all 
acquisitions  from  major  systems  programs  to  individual  unit 
supply  and  service  requisitions.  The  purpose  of  the  GPP  is  to 
enhance  and  sustain  mission  readiness  through  cost  effective 
acquisition  that  achieves  compliance  and  reduces  resource 
consumption  and  solid  and  hazardous  waste  generation.  Consistent 
with  requirements  of  Federal  procurement  preference  programs, 
green  products  or  services  must  be  considered  as  the  first  choice 
in  all  procurements  including,  but  not  limited  to  the  following 
categories:  office  products,  printing  services.  Fleet 

maintenance  products,  building  construction,  renovation  and 
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maintenance,  traffic  control,  park  and  recreation,  appliances, 
and  lighting.  In  every  procurement  action,  the  procurement 
request  originator  must  justify  a  decision  not  to  procure  a  green 
alternative  per  the  requirements  of  Federal  green  procurement 
preference  programs.  See  USD(AT&L)  memorandum  of  2  Dec  2008, 
"Updated  Green  Procurement  Program  (GPP)  Strategy"  which  is  an 
enclosure  of  DASN (RD&A) ALM  memorandum  16  Jan  2009,  "Updated  DoD 
Green  Procurement  Program  Strategy."  Also  see  DASN (AP) 
memorandum  18  Oct  2011,  "Improving  Sustainable  Acquisition  and 
Reporting . " 

6.3.6  Explosives  Safety 

All  ship  installations  of  new  or  modified  weapons,  or 
weapons  systems,  shall  be  formally  reviewed  and  approved  for 
safety  during  the  System  Development  and  Demonstration  phase  per 
reference  (a) .  Weapons  and  explosives  risks  shall  be  identified 
and  managed  using  the  process  identified  in  reference  (x) ,  and 
shall  be  briefed  to  the  Navy' s  Weapons  System  Explosives  Safety 
Review  Board  (WSESRB)  per  reference  (y) . 

6.3.7  Aviation  and  Ship  Critical  Safety  Items  (CSIs) 

Aviation  and  Ship  Critical  Safety  Items  (CSIs)  are  parts 
whose  failure  would  have  catastrophic  consequences  to  an 
aircraft,  a  ship,  unmanned  air  vehicles,  aircraft  launch  and 
recovery  equipment,  aviation  weapons  and  equipment,  and 
associated  aviation  support  equipment  in  which  they  are  used. 

CSIs  represent  less  than  five  percent  of  the  total  population  of 
replenishment  parts  used  in  aviation  systems,  but  the 
implications  of  failure  require  that  they  be  identified  and 
carefully  managed  from  design  through  to  disposal.  Rather  than 
repeat  existing  and  proposed  policies,  the  below  provides  source 
information  and  summaries  of  key  aviation  and  ship  CSI  statutes, 
regulations,  instructions,  and  guidance. 

Reference  (z)  established  policy,  procedures,  and 
responsibilities  for  the  life-cycle  management  of  items  critical 
to  naval  aviation  safety.  Reference  (z)  standardized 
terminology,  definitions,  criteria,  and  management  requirements 
across  the  military  Services,  Defense  Logistics  Agency  (DLA) ,  and 
Defense  Contract  Management  Agency  (DCMA)  when  they  are  involved 
in  designing,  acquiring,  repairing  or  overhauling,  or  supporting 
naval  aviation  systems  and  equipment.  Reference  (aa) ,  Section 
C8.5,  established  procedures  for  controlling  aviation  CSIs. 

Because  of  concerns  regarding  proper  identification  and 
life-cycle  management  of  CSIs,  reference  (ab) ,  Section  802 
(codified  in  10  U.S.C.  Section  2319),  established  the  requirement 
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for  the  Secretary  of  Defense  to  prescribe  policy  for  the  quality 
control  of  aviation  CSIs.  Specifically,  reference  (ab) ,  Section 
802,  required  that  1)  Desiqn  Control  Activities  establish  a 
process  to  identify  and  manage  aviation  CSIs;  2)  aviation  CSIs  be 
purchased  only  from  sources  approved  by  the  Design  Control 
Activity;  and  3)  delivered  aviation  CSIs  meet  requirements 
established  by  the  Design  Control  Activity.  As  defined  by 
reference  (ab) ,  Section  802,  the  Design  Control  Activity  is  the 
systems  command  of  a  military  department  specifically  responsible 
for  ensuring  the  airworthiness  of  an  aviation  system  or  equipment 
in  which  aviation  CSIs  will  be  used.  Additionally,  Public  Law 
108-87  (Department  of  Defense  Appropriations  Act,  2004;  30  Sep 
2003) ,  Section  8143,  required  the  Secretary  of  Defense  to  report 
on  the  Department  of  Defense's  process  to  track  defective  parts 
that  were  potentially  safety-critical  and  the  DoD' s  standards  to 
ensure  timely  notification  of  contracting  offices  and  contractors 
regarding  defective  safety-critical  parts. 

6.3.8  Corrosion  Prevention  and  Control 

At  the  time  of  program  initiation,  the  PM  should  identify 
the  corrosion  susceptibility  of  the  prospective  system.  For  all 
programs  deemed  "corrosion  susceptible,"  the  following  should 
apply.  The  PM  should  establish  a  corrosion  prevention  and 
control  program  that  identifies  attributes  of  the  system's  design 
and  construction  that  are  likely  to  facilitate  or  exacerbate 
corrosion  during  operational  use.  The  PM  should  adopt 
environmentally-compliant  materials  selection  and  corrosion 
prevention  techniques  during  the  design  and  manufacture  of  weapon 
systems.  The  PM  may  prepare  a  Life  Cycle  Corrosion  Management 
Plan  early  in  the  program  life  cycle  (during  phase  B) .  Elements 
of  such  a  plan  may  include,  as  appropriate: 

a.  Materials  and  processes  selection  for  corrosion 
performance  and  life  cycle  costs 

b.  Corrosion  mapping  of  deployed  assets  to  better  manage 
and  mitigate  corrosion 

c.  Detecting  and  correcting  corrosion  to  avoid 
unnecessary  rework  and  overhaul 

d.  Preventative  inspection  requirements  at  each  level  of 
maintenance 

e.  Advanced  planning  for  the  insertion  of  new  corrosion 
prevention  technologies 

f.  Training  and  qualifying  personnel  in  corrosion 
cleaning,  repairs,  assessment,  identification,  treatment. 
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preservation,  lubrication,  hazardous  waste  disposal,  and 
reporting . 

Guidance  for  corrosion  prevention  and  control  is  available 
in  a  DASN (RD&A) ACQ  Technical  Bulletin  -  "Corrosion  Prevention  and 
Detection "  which  can  be  found  at 

http : / / acquisition . navy .mil/ con tent /view/ full/ 1387.  See  the 
Defense  Acquisition  Guidebook  for  implementation  guidance  for  all 
DON  ACAT  programs . 
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Annex  6 -A 

Systems  Engineering  Plan  (SEP)  Signature  Pages 

SEP  Approval  Page  for  ACAT  ID/IC/IAM/IAC  programs 

SEP  Coordination  Page  for  ACAT  ID/IC/IAM/IAC  programs 

SEP  Coordination/Approval  Page  for  ACAT  II/Special  Interest 
programs 

SEP  Coordination/Approval  Page  for  ACAT  III/IV  programs 
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Systems  Engineering  Plan  (SEP)  Signature  Pages 
SEP  Approval  Page  For  ACAT  ID/IC/IAM/IAC  Programs 

[PROGRAM  NAME  -  ACAT  LEVEL] 


SYSTEMS  ENGINEERING  PLAN  (SEP) 

VERSION:  _ 

SUPPORTING  MILESTONE:  _ 

MONTH  DAY,  YEAR:  _ 


OSD  APPROVAL: 


Name  Date 

Deputy  Assistant  Secretary  of  Defense 

Systems  Engineering 

(for  MDAPs  and  MAIS  Programs) 


Distribution  is  limited  to  U.S.  Government  agencies  only.  Other  requests  for 
this  document  must  be  referred  to  the  ASN (RD&A)  Chief  Systems  Engineer. 

CLASSIFIED  BY: _ 

DECLASSIFY  ON: 
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SEP  Coordination  Page  For  ACAT  ID/IC/IAM/IAC  Programs 

[PROGRAM  NAME  -  ACAT  LEVEL] 

SYSTEMS  ENGINEERING  PLAN 

VERSION:  _ 

SUPPORTING  MILESTONE:  _ 

MONTH  DAY,  YEAR:  _ 


SUBMITTED  BY: 


Name  Date  Name  Date 

Lead/Chief  Engineer  Program  Manager 


CONCURRENCE : 


Name  Date  Name  Date 

SYSCOM  Chief  Engineer  PEO/SYSCOM/DRPM 


COMPONENT  APPROVAL: 


Name  Date 

DASN(RDTSE)  Chief  Systems  Engineer 
(per  ASN (RD&A)  memo  of  16  Nov  2007) 


Distribution  is  limited  to  U.S.  Government  agencies  only.  Other  requests  for 
this  document  must  be  referred  to  the  ASN (RD&A)  Chief  Systems  Engineer. 

CLASSIFIED  BY: _ 

DECLASSIFY  ON: 
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SEP  Coordination/Approval  Page  For  ACAT  I I /Special 

Interest  Programs 

[PROGRAM  NAME  -  ACAT  LEVEL] 

SYSTEMS  ENGINEERING  PLAN  (SEP) 

VERSION:  _ 

SUPPORTING  MILESTONE:  _ 

MONTH,  DAY  YEAR:  _ 


SUBMITTED  BY: 

Name 

Lead/Chief  Engineer 

Date  Name 

Program  Manager 

Date 

CONCURRENCE : 

Name 

SYSCOM  Chief  Engineer 

Date  Name 

PEO/SYSCOM/DRPM 

Date 

APPROVAL : 

Name 

DASN (RDT&E)  Chief  Systems 
(per  ASN (RD&A)  memo  of  16 

Date 

Engineer 

Nov  2007) 

Distribution  is  limited  to  U.S.  Government  agencies  only.  Other  requests  for 
this  document  must  be  referred  to  ASN (RD&A)  Chief  Systems  Engineer. 

CLASSIFIED  BY: _ 

DECLASSIFY  ON: 
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SEP  Coordination/Approval  Page  For  ACAT  III/IV  Programs 

[PROGRAM  NAME  -  ACAT  LEVEL] 

SYSTEMS  ENGINEERING  PLAN  (SEP) 

VERSION:  _ 

SUPPORTING  MILESTONE:  _ 

MONTH,  DAY  YEAR:  _ 

SUBMITTED  BY: 

Name  Date  Name  Date 

Lead/Chief  Engineer  Program  Manager 


CONCURRENCE : 


Name  Date  Name  Date 

SYSCOM  Chief  Engineer  PEO/SYSCOM/DRPM 


APPROVAL : 


Name  Date 

Milestone  Decision  Authority 
(per  ASN (RD&A)  memo  of  16  Nov  2007) 


Distribution  is  limited  to  U.S.  Government  agencies  only.  Other  requests  for 
this  document  must  be  referred  to  ASN (RD&A)  Chief  Systems  Engineer. 

CLASSIFIED  BY: _ 

DECLASSIFY  ON:  . 
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Chapter  7 

Acquisition  of  Services 


7 . 1  Introduction 

7 . 2  Applicability 

7 . 3  Definitions 

7 . 4  Responsibility 

7 . 5  Review  and  Approval  Thresholds 

7 . 6  Review  Procedures 

7 . 7  Outcomes 

7 . 8  Metrics 

7 . 9  Data  Collection 

7.10  Execution  Reviews 

7.11  Decision  Authority  Acquisition  Management  Responsibilities 

7 . 12  Independent  Management  Reviews  (Hereafter  Referred  to  as 
"Peer  Reviews") 
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Chapter  8 

Program  Management 

References:  (a)  SECNAVINST  5420. 188F 

8 . 1  Assignment  of  Program  Executive  Responsibilities 

8 . 2  International  Cooperative  Program  Management 

Participation  in  international  cooperative  programs 
requires  the  establishment  of  an  international  agreement. 
International  agreements  normally  include  details  of  financial 
arrangements,  security  considerations  and  procedures,  program 
management  structure,  use  and  disclosure  of  information  between 
participants,  and  sales  and  transfers  of  information  and 
equipment  to  third  parties.  Staffing  of  international  agreements 
and  supporting  documentation  will  include  coordination  with 
appropriate  financial,  legal,  and  international  policy 
agencies/offices,  and  will  be  managed  by  Navy  International 
Program  Office  (IPO) .  Program  proponents  should  consult  with 
Navy  IPO  for  guidance  on  the  latest  policies  and  procedures  for 
developing  and  implementing  international  agreements. 

8 . 3  Joint  Program  Management 

For  joint  programs,  an  operating  agreement  will  be 
prepared  and  should  identify  responsibilities  for  funding, 
participation  in  joint  program  decision-making,  program 
information/documentation  preparation,  endorsement,  and  approval 
and  other  topics  as  appropriate. 

When  a  DON  activity  is  considering  involvement  in  another 
service  program  that  is  past  the  Full-Rate  Production  Decision 
Review,  and  when  there  has  been  no  previous  formal  involvement, 
the  decision  to  forward  funds  to  the  lead  service  will  be 
supported  by: 

a.  Program  Information/Documentation .  Other  Service  or 
agency  program  information/documentation  supported  by  a  DON 
endorsement  will  be  used  to  the  maximum  extent  possible.  Any 
unique  DON  activity  requirements  will  be  addressed  in  supporting 
documentation . 

b.  Decision .  The  information/documentation  requirements 
to  support  the  DON  activity' s  decision  to  participate  in  other 
Services'  or  agencies'  programs  will  follow  the  general 
guidelines  of  reference  (a)  . 

8 . 4  Program  Management  Agreements  (PMAs) 
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Chapter  9 
Glossary 


This  glossary  contains  terms  used  in  SECNAVINST  5000. 2E. 
Entries  are  in  alphabetical  order.  In  some  cases  the  reader  is 
referred  to  other  instructions  where  a  fuller  discussion  is 
already  provided. 

Abbreviated  Acquisition  Program  (AAP) 

-  a  weapon  system  program:  (1)  whose  cost  is  less  than  all  of  the 
following  dollar  thresholds:  $10  million  in  total  development 
cost  for  all  fiscal  years,  $25  million  in  total  production  or 
services  cost  for  any  fiscal  year,  and  $50  million  in  total 
production  or  services  cost  for  all  fiscal  years,  (2)  which  does 
not  affect  the  military  characteristics  of  ships  or  aircraft  or 
involve  combat  capability,  (3)  which  does  not  require  an 
operational  test  and  evaluation,  and  (4)  is  so  designated  by  the 
cognizant  PEO/SYSCOM  Commander /DRPM. 

-  an  information  technology  program:  (1)  whose  cost  is  less  than 
all  of  the  following  dollar  thresholds:  $15  million  in  program 
costs  for  any  single  year  and  $30  million  in  total  program  costs, 
(2)  which  does  not  require  an  operational  test  and  evaluation, 
and  (3)  is  so  designated  by  ASN (RD&A)  or  designee,  or  PEO/SYSCOM 
Commander /DRPM. 

Acquisition  Category  IV  -  a  program  not  meeting  the  criteria  for 
ACAT  I,  II,  or  III.  ACAT  IV  programs  are  ACAT  IVT  or  ACAT  IVM 
programs.  ACAT  IVT  programs  require  Operational  Test  and 
Evaluation  (OT&E) .  ACAT  IVM  programs  are  monitored  by 
COMOPTEVFOR  or  Director,  MCOTEA,  but  do  not  require  OT&E. 

Acquisition  Coordination  Team  (ACT)  -  a  team,  normally  composed 
of  representatives  of  the  requirements  generation,  acquisition, 
testing  and  financial  communities,  required  for  ACAT  I  and  II 
programs.  The  ACT  is  specifically  used  to  oversee  the  analysis 
of  alternatives,  form  a  tailoring  agreement  proposal  (for  program 
documentation  and  structure) ,  develop  an  acquisition  strategy  and 
resolve  issues  at  the  lowest  level  possible.  ACT's  are 
encouraged,  but  not  required,  for  ACAT  III  and  IV  programs.  See 
SECNAVINST  5420.188  series. 

Acquisition  Program  -  a  directed,  funded  effort  that  provides  a 
new,  improved,  or  continuing  materiel,  weapon  or  information 
system,  or  service  capability  in  response  to  an  approved  need 
(DoDD  5000 . 01) . 
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Acquisition  Program  Baseline  (APB)  -  a  document  that  contains  the 
cost,  schedule  and  performance  objectives  and  thresholds  of  the 
program  beginning  at  program  initiation.  It  contains  only  the 
most  important  parameters  that,  if  the  thresholds  were  not  met, 
the  MDA  would  require  a  reevaluation  of  alternative  concepts  or 
design  approaches. 

Acquisition  Review  Board  (ARB)  -  the  senior-level  forum  for 
advising  the  PEO/SYSCOM/DRPM  on  critical  decisions  concerning  all 
ACAT  I  and  II  programs  prior  to  proceeding  to  a  program  decision 
meeting  (PDM)  with  ASN (RD&A) .  For  ACAT  III  and  IV  programs,  the 
ARB  serves  as  the  program  decision  point  meeting.  The  ARB  is 
chaired  by  the  PEO/SYSCOM/DRPM  and  participation  is  determined  by 
the  milestone  decision  authority.  Representatives  of  the  CNO/CMC 
are  also  invited  to  participate. 

Acquisition  Strategy  (AS)  -  an  acquisition  strategy  documents  a 
program  manager's  (PM's)  top-level  business  and  technical 
management  strategy  to  achieve  life-cycle  program  objectives 
within  the  resource  constraints  imposed.  It  is  the  framework  for 
planning,  directing,  contracting,  and  managing  a  program.  It 
provides  a  program  structure  and  master  schedule  of  events  for 
technology  development,  system  development  and  demonstration, 
test  and  evaluation,  production  and  deployment,  operations  and 
support,  other  activities  essential  for  program  success,  and  is 
the  basis  for  formulating  program  plans.  See  chapter  2, 
paragraph  2.4,  of  this  guidebook  for  elements  of  an  acquisition 
strategy . 

Acquisition  Plan  (AP)  -  an  acquisition  plan  documents  the 
acquisition  planning  required  to  develop,  test,  and  procure 
program  end  items  and  the  support  services  for  such  end  items. 

An  acquisition  plan  is  required  by  Part  7  of  the  Federal 
Acquisition  Regulation  (FAR)  and  by  Part  207  of  the  Defense 
Federal  Acquisition  Regulation  Supplement  (DFARS)  above  certain 
dollar  thresholds  defined  therein.  An  acquisition  plan  may  be  a 
stand-alone  plan,  may  be  part  of  an  acquisition  strategy,  or  may 
be  part  of  a  single  acquisition  management  plan  (SAMP)  as  long  as 
all  of  the  requirements  of  the  FAR,  DFARS,  and  the  Navy-Marine 
Corps  Acquisition  Regulation  Supplement  (NMCARS)  are  satisfied. 

Advanced  Concept  Technology  Demonstration  (ACTD)  -  a  means  of 
demonstrating  the  use  of  mature  technology  in  a  system  to  address 
urgent  military  needs.  The  ACTD  is  not  an  acquisition  program 
but  if  additional  units  beyond  the  capability  created  are 
required,  the  ACTD  should  be  converted  into  an  acquisition 
program . 

Automated  Information  System  (AIS)  -  an  acquisition  program  that 
acquires  Information  Technology  (IT),  except  IT  that: 
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(1)  involves  equipment  that  is  an  integral  part  of  a  weapon  or 
weapon  system;  or 

(2)  is  a  tactical  communication  system. 

Critical  Application  Item  (CAI)  -  an  item  that  is  essential  to 
weapon  system  performance  or  operation,  or  the  preservation  of 
life  or  safety  of  operating  personnel,  as  determined  by  the 
military  services.  The  subset  of  CAIs  whose  failure  could  have 
catastrophic  or  critical  safety  consequences  are  known  as 
Critical  Safety  Items. 

Critical  Infrastructure  Protection  (CIP)  -  is  mission  protection 
and  the  identification,  assessment,  and  assurance  of  cyber  and 
physical  infrastructure  that  support  mission  critical 
capabilities  and  requirements,  to  include  political,  economic, 
technological,  and  informational  security  environments  essential 
to  the  execution  of  the  National  Military  Strategy. 

Critical  Safety  Item  (CSI)  -  a  part,  assembly,  installation 
equipment,  launch  equipment,  recovery  equipment,  or  support 
equipment  for  an  aircraft  or  aviation  weapons  system  that 
contains  a  characteristic  any  failure,  malfunction,  or  absence  of 
which  could  cause  a  catastrophic  or  critical  failure  resulting  in 
loss  or  serious  damage  to  the  aircraft  or  weapons  system,  an 
unacceptable  risk  of  personal  injury  or  loss  of  life,  or  an 
uncommanded  engine  shutdown  that  jeopardizes  safety. 

Defense  Business  System  (DBS)  -  an  information  system,  other  than 
a  National  Security  System,  operated  by,  for,  or  on  behalf  of  the 
Department  of  Defense,  including  financial  systems,  mixed 
systems,  financial  data  feeder  systems,  and  information 
technology  and  information  assurance  infrastructure,  used  to 
support  business  activities,  such  as  acquisition,  financial 
management,  logistics,  strategic  planning  and  budgeting, 
installations  and  environment,  and  human  resource  management. 

Developing  Agency/Activity  (DA)  -  the  PEO,  SYSCOM,  DRPM,  or  other 
organizations  assigned  responsibility  for  program  execution. 

Environment,  Safety,  and  Occupational  Health  (ESOH)  -  refers  to 
the  combination  of  disciplines  that  encompass  the  processes  and 
approaches  for  addressing  laws,  regulations.  Executive  Orders 
(EO) ,  DoD  policies,  environmental  compliance,  and  hazards 
associated  with  environmental  impacts,  system  safety  (e.g., 
platforms,  systems,  system-of-systems ,  weapons,  explosives, 
software,  ordnance,  combat  systems) ,  occupational  safety  and 
health,  hazardous  materials  management,  and  pollution  prevention. 
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Evolutionary  Acquisition  (EA)  -  an  acquisition  strategy  whereby  a 
basic  capability  is  fielded  with  the  intent  to  procure  and  field 
additional  capabilities  via  blocks  in  the  form  of  modifications 
to  the  basic  capability  fielded.  This  technique  is  often  found 
in  the  development,  production  and  fielding  of  programs  involving 
rapidly  advancing  technology  and  software  and  with  programs 
involving  rapidly  changing  requirements. 

Extension  of  Application  -  an  acquisition  strategy  whereby  an 
existing  system,  subsystem  or  equipment  is  selected  to  be 
extended  in  its  application  to  a  new  host  platform.  This 
strategy  usually  does  not  require  an  operational  evaluation 
(OPEVAL)  in  the  new  host  platform,  but  a  period  of  follow-on 
operational  test  and  evaluation  (FOT&E)  is  usually  required  to 
ensure  that  the  system,  subsystem  or  equipment  integration  has 
not  degraded  performance,  including  the  performance  of  the  host 
platform . 

Failure  Modes,  Effects  and  Criticality  Analysis  -  the  analysis  of 
the  various  ways  in  which  equipment  is  expected  to  fail,  the 
failure's  resultant  effects,  and  impact  on  mission 
accomplishment . 

Family  of  Systems  (FoS)  -  a  set  or  arrangement  of  independent 
systems  that  can  be  arranged  or  interconnected  in  various  ways  to 
provide  different  capability  needs.  The  mix  of  systems  can  be 
tailored  to  provide  desired  capabilities  dependent  on  the 
situation . 

FORCEnet  -  FORCEnet  is  the  Navy  and  Marine  Corps  initiative  to 
achieve  Joint  Transformation  by  providing  robust  information 
sharing  and  collaboration  capabilities  across  the  Naval/ Joint 
force.  FORCEnet  capabilities  are  described  by  SECNAVINST 
5000. 2E,  chapter  1,  paragraph  1.1. 2. 5. 

Habitability  -  is  that  military  characteristic  of  Navy  ships 
directed  toward  satisfying  personnel  needs  which  are  dependent 
upon  physical  environment. 

Hazardous  Material  -  material  that  due  to  its  chemical,  physical, 
or  biological  nature  causes  safety,  public  health,  or 
environmental  concerns  that  elevate  efforts  to  manage. 

Health  Hazard  -  any  real  or  potential  condition  that  can  cause 
injury,  illness,  or  death  to  personnel;  damage  to  or  loss  of  a 
system,  equipment  or  property;  or  damage  to  the  environment. 

Human  Factors  Engineering  (HFE)  -  the  systems  engineering 
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discipline  that  addresses  integration  of  human  characteristics 
into  system  definition,  design,  development,  and  evaluation  to 
optimize  human-machine  performance  under  operational  conditions. 

Human  Systems  Integration  (HSI)  -  the  integrated  and 
comprehensive  analysis,  design,  and  assessment  of  requirements, 
concepts  and  resources  for  system  manpower,  personnel,  training, 
safety  and  occupational  health,  habitability,  personnel 
survivability,  and  human  factors  engineering  (HFE) . 

Information  Resources  (IR)  -  information  and  related  resources, 
such  as  personnel,  equipment,  funds,  and  information  technology 
(44  U.S.C.  Section  3502(6)).  Excluded  are  computer  resources, 
both  hardware  and  software,  that  are:  physically  part  of, 
dedicated  to,  or  essential  in  real  time  to  the  mission 
performance  of  weapons  systems. 

Information  System  -  a  discrete  set  of  information  resources 
organized  for  the  collection,  processing,  maintenance,  use, 
sharing,  dissemination,  or  disposition  of  information  (44  U.S.C. 
Section  3502 ( 8 ) ) . 

Information  Technology  (IT)  -  any  equipment,  or  interconnected 
system  or  subsystem  of  equipment,  that  is  used  in  the  automatic 
acquisition,  storage,  manipulation,  management,  movement, 
control,  display,  switching,  interchange,  transmission,  or 
reception  of  data  or  information. 

(1)  the  term  "equipment"  means  any  equipment  used  by  a 
Component  directly  or  is  used  by  a  contractor  under  a  contract 
with  the  Component  that  requires  the  use  of  the  equipment,  or  the 
use,  to  a  significant  extent,  of  such  equipment  in  the 
performance  of  a  service  or  the  furnishing  of  a  product. 

(2)  the  term  "IT"  includes  computers,  ancillary  equipment, 
software,  firmware  and  similar  procedures,  services  (including 
support  services),  and  related  resources.  It  does  not  include 
any  equipment  that  is  acquired  by  a  Federal  contractor  incidental 
to  a  Federal  contract. 

This  "IT"  definition  is  from  the  Clinger-Cohen  Act  (Public 
Law  104-106,  10  Feb  96,  Section  5002)  (40  U.S.C.  Section 

1401  (3) )  . 

Per  44  U.S.C.  Section  3502(9),  the  term  "IT"  as  defined  in 
the  Paperwork  Reduction  Act  (Public  Law  104-13) ,  as  amended  by 
Public  Law  104-106  Section  5605,  does  NOT  include  National 
Security  Systems  as  defined  in  the  Clinger-Cohen  Act  (Public  Law 
104-106,  10  Feb  96,  Section  5142)  (40  U.S.C.  Section  1452). 
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Information  Technology  (IT)  System  -  any  system  that  is  an 
interconnected  system  or  subsystem  of  equipment,  that  is  used  in 
the  automatic  acquisition,  storage,  manipulation,  management, 
movement,  control,  display,  switching,  interchange,  transmission, 
or  reception  of  data  or  information,  including  computers, 
ancillary  equipment,  software,  firmware  and  similar  procedures, 
services  (including  support  services) ,  related  resources, 
automated  information  systems  (AISs)  such  as  electronic 
commerce/electronic  data  interchange,  non-tactical  networks, 
messaging  systems,  and  base  level  infrastructure. 

Information  Technology  Program  -  a  program  that  acquires  an 
automated  information  system  (AIS) ,  except  AIS  that: 

(1)  involves  equipment  that  is  an  integral  part  of  a  weapon  or 
weapon  system;  or 

(2)  is  a  tactical  communication  system. 

Integration  -  the  process  of  combining  the  electrical/electronic/ 
mechanical/human  components  of  a  system  into  an  overall  system. 
Also  the  process  of  combining  systems  of  a  set  of  systems  into  a 
system  of  systems  (SoS)  (adapted  from  IEEE  Standard  610.12-1990). 

Interoperability  -  (1)  the  ability  of  systems,  units,  or  forces 
to  provide  services  to  and  accept  services  from  other  systems, 
units,  or  forces  and  to  make  use  of  the  services,  units,  or 
forces  and  to  use  the  services  so  exchanged  to  enable  them  to 
operate  effectively  together.  (2)  the  condition  achieved  among 
communications-electronics  systems  or  items  of  communications- 
electronics  equipment  when  information  or  services  can  be 
exchanged  directly  and  satisfactorily  between  them  and/or  their 
users.  (3)  the  ability  of  hardware  to  physically  and 
mechanically  interface,  operate  with,  and  support  other  hardware. 
The  degree  of  interoperability  should  be  defined  when  referring 
to  specific  cases. 

Joint  Potential  Designator  -  a  categorization  indicating  the 
degree  to  which  a  program  has  potential  for  joint  use. 

Level  of  Repair  Analysis  -  the  analysis  of  a  repairable  item  to 
determine  whether  organizational,  intermediate  or  depot  is  the 
most  appropriate  level  of  repair. 

Maintenance  Concept  -  expresses  the  overall  maintenance  plan  for 
maintaining  the  platform  and  system  at  a  defined  level  of 
material  readiness  in  support  of  the  operational  scenario.  It 
includes  preventive  maintenance,  corrective  maintenance  and 
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depot-level  maintenance.  It  should  consider  maintainability  at 
all  maintenance  levels  (i.e.,  organizational,  intermediate,  and 
depot)  as  well  as  address  the  scope  of  required  work  at  each 
level . 

Maintenance  Releases  -  maintenance  releases  are  "fixes"  for  minor 
problems  and  will  not  require  testing  by  COMOPTEVFOR.  However, 
COMOPTEVFOR  testing  is  appropriate  when  maintenance  releases  are 
so  numerous  as  to  jeopardize  the  reliability  and  performance  of 
the  software.  In  such  cases,  COMOPTEVFOR  will  determine  the  need 
and  extent  of  operational  testing  and  inform  the  DA,  with  an 
information  copy  to  CNO  (N84)  and  program  sponsor. 

Major  Automated  Information  System  (MAIS)  Acquisition  Program  -  a 

program  estimated  by  the  DoD  CIO  to  require  program  costs  for  any 
single  year  in  excess  of  $32  million  (FY  2000  constant  dollars) , 
total  program  costs  in  excess  of  $126  million  (FY  2000  constant 
dollars),  or  total  life-cycle  costs  in  excess  of  $378  million  (FY 
2000  constant  dollars) ,  or  those  otherwise  designated  by  the  DoD 
CIO  to  be  ACAT  IA.  ACAT  IA  programs  have  two  sub-categories 
(ACAT  I AM  and  I AC) . 

Major  Contract  -  a  contract  that  is  greater  than  $50  million  in 
then-year  dollars  (DODI  5000.02,  enclosure  4,  Table  4) . 

Major  Defense  Acquisition  Program  -  a  program  estimated  by  the 
Under  Secretary  of  Defense  (Acquisition,  Technology  and 
Logistics)  (USD(AT&L))  to  require  eventual  expenditure  for 
research,  development,  test,  and  evaluation  of  more  than  $365 
million  (Fiscal  Year  (FY)  2000  constant  dollars)  or  procurement 
of  more  than  $2,190  billion  (FY  2000  constant  dollars),  or  those 
otherwise  designated  by  the  USD(AT&L)  to  be  ACAT  I.  ACAT  I 
programs  have  two  sub-categories  (ACAT  ID  and  IC) . 

Major  Releases  -  major  software  releases  will  require  operational 
testing  either  as  full  OT&E  or  FOT&E  by  COMOPTEVFOR.  Such 
releases  involve  a  change  that  adds  new  functions  or  warfare 
capabilities,  interfaces  with  a  different  weapon  system, 
redesigns  the  software  architecture,  ports  the  software  to  a  new 
hardware  platform,  or  rewrites  the  software  in  different 
language . 

Manpower  Requirements  -  the  number  and  type  of  personnel 
(military,  civilian,  or  contractor)  required  and  potentially 
available  to  operate,  maintain,  support,  and  provide  training  for 
systems  per  10  U.S.C.  Section  2434. 

Measure  of  Effectiveness  (MOE)  -  the  operational  performance 
parameter  that  specifies  a  mission  area  capability  or 
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characteristic  as  identified  in  the  capability 
development/production  document  (CDD/CPD). 

Measure  of  Performance  (MOP)  -  testable  parameters  that  relate 
directly  to  a  MOE  such  that  the  effect  of  a  change  in  the  MOP  can 
be  related  to  change  in  the  MOE.  MOPs  are  identified  in  the  test 
and  evaluation  master  plan  (TEMP) . 

Minor  Releases  -  minor  releases  are  improvements  that  do  not  add 
any  new  functions,  warfare  capability,  or  interfaces  and  do  not 
meet  any  of  the  criteria  of  a  major  release.  The  content  and 
scope  of  minor  releases  will  be  reviewed  by  Commander, 

Operational  Test  and  Evaluation  Forces  (COMOPTEVFOR)  for 
operational  testing  requirements  using  the  OSD  Director, 
Operational  Test  and  Evaluation  (DOT&E)  guidelines  for 
operational  testing  of  software.  COMOPTEVFOR  will  determine  the 
need  for  and  extent  of  operational  testing  and  inform  the  DA,  via 
message,  with  an  information  copy  to  CNO  (N84)  and  program 
sponsor.  Numerous  minor  releases  can  lead  to  degraded  software 
reliability  and  performance,  in  such  cases,  OPTEVFOR  will 
determine  the  need  for  and  extent  of  operational  testing  and 
inform  the  developing  agency/activity  (DA),  via  message,  with  an 
information  copy  to  CNO  (N84)  and  program  sponsor. 

Mission  Capability  -  either  a  direct  warfighting  capability  or  a 
function  that  crosses  several  warfighting  capabilities.  Two 
examples,  of  many,  that  are  direct  warfighting  capabilities  are 
theater  air  and  missile  defense  (TAMD)  and  time  critical  strike 
(TCS) .  Two  examples,  also  of  many,  that  are  functions  that  cross 
several  warfighting  capabilities  are  targeting  and  command  and 
control  (C2 ) . 

Mission-Critical  Information  System  -  a  system  that  meets  the 
definitions  of  "information  system"  and  "national  security 
system"  the  loss  of  which  would  cause  the  stoppage  of  warfighter 
operations  or  direct  mission  support  of  warfighter  operations. 
(Note:  The  designation  of  mission-critical  shall  be  made  by  a  DoD 
Component  Head,  a  Combatant  Commander,  or  their  designee.  A 
financial  management  Information  Technology  (IT)  system  shall  be 
considered  a  mission-critical  IT  system  as  defined  by  the  Under 
Secretary  of  Defense  (Comptroller) . )  A  "Mission-Critical 
Information  Technology  System"  has  the  same  meaning  as  a 
"Mission-Critical  Information  System."  For  additional 
information,  see  DOD  Instruction  5000.02,  Enclosure  5. 

Mission-Essential  Information  System  -  a  system  that  meets  the 
definition  of  "information  system"  that  the  acquiring  DoD 
Component  Head  or  designee  determines  is  basic  and  necessary  for 
the  accomplishment  of  the  organizational  mission.  (Note:  The 
designation  of  mission-essential  shall  be  made  by  a  DoD  Component 
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Head,  a  Combatant  Commander,  or  their  designee.  A  financial 
management  IT  system  shall  be  considered  a  mission-essential  IT 
system  as  defined  by  the  Under  Secretary  of  Defense 
(Comptroller) . )  A  "Mission-Essential  Information  Technology 
System"  has  the  same  meaning  as  a  "Mission-Essential  Information 
System."  For  additional  information,  see  DOD  Instruction 
5000.02,  Enclosure  5. 

National  Security  System  -  any  telecommunications  or  information 
system  operated  by  the  U.S.  Government,  the  function,  operation, 
or  use  of  which: 

(1)  involves  intelligence  activities; 

(2)  involves  cryptologic  activities  related  to  national 
security; 

(3)  involves  command  and  control  of  military  forces; 

(4)  involves  equipment  that  is  an  integral  part  of  a  weapon 
or  weapons  system; 

(5)  subject  to  the  limitation  below,  is  critical  to  the 
direct  fulfillment  of  military  or  intelligence  missions.  This 
does  not  include  a  system  that  is  to  be  used  for  routine 
administrative  and  business  applications  (including  payroll, 
finance,  logistics,  and  personnel  management  applications) . 

This  definition  is  from  the  Clinger-Cohen  Act  (Public  Law 
104-106,  10  Feb  96,  Section  5142)  (40  U.S.C.  Section  1452). 

Network  Centric  -  exploitation  of  advancing  technology  that  moves 
from  an  application-centric  to  a  data-centric  paradigm  -  that  is, 
providing  users  the  ability  to  access  applications  and  services 
through  Web  services  -  an  information  environment  comprised  of 
interoperable  computing  and  communication  components  (GIG  MA 
ICD)  . 

Net-Centric  Warfare  (NCW)  -  an  information  superiority-enabled 
concept  of  operations  that  generates  increased  combat  power  by 
networking  sensors,  decision  makers,  and  shooters  to  achieve 
shared  awareness,  increased  speed  of  command,  higher  tempo  of 
operations,  greater  lethality,  increased  survivability,  and  a 
degree  of  self-synchronization.  In  essence,  NCW  translates 
information  superiority  into  combat  power  by  effectively  linking 
knowledgeable  entities  in  the  battle  space  (GIG  ES  ICD) . 

Non-Acquisition  Program  -  an  effort  that  does  not  directly  result 
in  the  acquisition  of  a  system,  subsystem,  or  equipment  for 
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operational  use.  Non-acquisition  programs  are  research  and 
development  funded  which  may  have  some  application  to  an 
acquisition  program  in  the  future.  These  efforts  often  provide  a 
proof  of  principle  or  technology  application.  (see  SECNAVINST 
5000. 2E,  chapter  1,  paragraph  1.7) 

Personnel  -  the  human  knowledge,  skills,  abilities,  competencies, 
characteristics,  and  capabilities  required  to  operate,  maintain, 
train,  and  support  each  capability  and/or  system  in  peacetime  and 
war . 

Personnel  Survivability  -  the  characteristics  of  a  system  that 
can  reduce  fratricide,  detectability,  and  probability  of  being 
attacked,  as  well  as  minimize  system  damage,  personnel  injury, 
and  cognitive  and  physical  fatigue. 

Production  Acceptance  T&E  (PAT&E)  -  test  and  evaluation  conducted 
on  production  items  to  ensure  systems  meet  contract 
specifications  and  requirements. 

Program  Decision  Meeting  (PDM)  -  the  Department's  senior-level 
forum  for  advising  the  Assistant  Secretary  of  the  Navy  (Research, 
Development  and  Acquisition)  on  critical  decisions  concerning 
ACAT  IC  and  II  programs.  The  PDM  is  chaired  by  the  ASN (RD&A)  and 
composed  of  the  Department's  senior  acquisition  officials,  DON 
CIO,  representatives  of  the  CNO/CMC,  and  others,  as  appropriate. 
See  SECNAVINST  5420.188  series. 

Program  Sponsor  -  in  coordination  with  the  resource  sponsor  where 
separately  assigned,  acts  as  the  user  representative  and  provides 
explicit  direction  with  regard  to  mission  and  operational 
requirements  generation  and  changes,  program  funding,  and 
preparation  and  approval  of  necessary  program  documentation  and 
program  decision  point  information. 

Rapid  Deployment  Capability  -  a  tailored  process  that  provides 
the  ability  to  react  immediately  to  a  newly  discovered  enemy 
threat,  potential  enemy  threat  or  to  respond  to  significant  and 
urgent  safety  situations  through  special,  tailored  acquisition 
procedures  using  off-the-shelf  technology. 

Rapid  Development  and  Deployment  Capability  -  a  tailored  process 
to  expedite  the  development  and  demonstration  of  prototype 
systems  with  new  technologies  to  meet  urgent  needs  of  deployed 
forces . 

Resource  Sponsor  -  where  separately  assigned  from  the  program 
sponsor,  is  responsible  for  program  budget  development, 
submission,  and  management. 
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Safety  -  the  systems  engineering  process  involving  hazard 
identification,  risk  evaluation,  design  analysis,  hazard 
mitigation/control  and  management.  The  process  manages  the 
design  and  operational  characteristics  of  a  system  that  eliminate 
or  minimize  the  possibilities  for  accidents  or  mishaps  caused  by 
human  error  or  system  failure. 

Software  Intensive  System  -  For  a  system  to  be  considered 
software-intensive,  its  software  must  be  the  largest  segment  with 
respect  to  system  development  costs,  or  functionality,  or 
development  risk,  or  development  time. 

The  three  general  classifications  of  DoD  software-intensive 
systems  are: 

(1)  Embedded  Systems 

(2)  Automated  Information  Systems 

(3)  Command,  Control,  Communications  and  Intelligence  (C3I) 
Systems.  (Defense  Acquisition  University  (DAU)  Systems 
Acquisition  Management  (SAM)  101  course  definition) 

Software  Qualification  Testing  (SQT)  -  post-Full-Rate  Production 
software  testing  conducted  by  an  independent  test  agency  for  the 
purpose  of  determining  whether  a  software  product  is  approved  for 
fleet  release. 

Standardization  -  a  process  used  to  achieve  the  greatest 
practicable  uniformity  of  items  of  supply  and  engineering 
practices,  to  insure  the  minimum  practicable  variety  of  such 
items  and  optimum  interchangeability  of  technical  information, 
training,  equipment  parts,  and  components. 

Supportability  -  ensuring  that  support  requirements  are  met  by 
system  introduction,  and  maintained  throughout  deployment,  at  or 
above  formal  threshold  levels.  Determining  the  most  cost 
effective  life-cycle  cost,  including  the  costs  for  information, 
infrastructure,  and  rapidly  acquired  and  rapidly  obsolete 
technology.  Planned  and  executed  concurrently  with  all  other 
systems  engineering,  and  a  primary  analysis  consideration  in 
acquiring  off-the-shelf  alternatives. 

System  of  Systems  -  a  set  or  arrangement  of  interdependent 
systems  that  are  related  or  connected  to  provide  a  given 
capability.  The  loss  of  any  part  of  the  system  will  degrade  the 
performance  or  capabilities  of  the  whole. 

T&E  Coordination  Group  -  a  forum  whose  purpose  is  to  coordinate 
and  resolve  more  complex  Navy  test  and  evaluation  (T&E)  issues. 
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including  urgent  test  and  evaluation  master  plan  (TEMP)  changes. 
The  forum  is  chaired  by  CNO  (N84)  and  membership  usually  includes 
CNO  staff,  program  manager  (PM) ,  OPTEVFOR  Assistant  Chief  of 
Staff,  and  ASN (RD&A)  program  staff  (including  Chief  Engineer  and 
others) . 

Test  and  Evaluation  Working-level  Integrated  Product  Team  (T&E 
WIPT)  -  a  forum  whose  purpose  is  to  discuss,  coordinate  and 
resolve  test  planning  goals  and  issues.  The  forum  is  chaired  by 
the  PM  or  the  PM' s  designated  representative.  Membership  is 
flexible  but  can  include  CNO  representatives,  SYSCOM  T&E 
representatives,  COMOPTEVFOR  staff,  ASN (RD&A)  staff,  OSD  and 
DOT&E  staff,  and  contractors. 

Threshold  -  the  value  of  a  baseline  parameter  that  represents  the 
minimum  acceptable  value  which,  in  the  user's  judgment,  is 
necessary  to  satisfy  the  need.  If  threshold  values  are  not 
achieved,  program  performance  is  seriously  degraded,  the  program 
may  be  too  costly,  or  the  program  may  no  longer  be  timely. 

Total  Life-Cycle  Cost  of  Ownership  -  life-cycle  ownership  cost 
includes  the  cost  to  develop,  acquire,  operate,  support,  and 
dispose  of  the  system  per  ASN (RD&A) ,  VCNO,  and  ACMC  joint  letter. 
Total  Ownership  Cost  (TOC)  Definition  for  the  Department  of  the 
Navy  (DON),  of  28  Jul  09.  Total  costs  are  determined  when 
acquisition  plans  and  strategies  make  trade-offs  to  optimize 
long-term  operations  and  support  considerations.  These  trade¬ 
offs  consider  lowest  total  ownership  cost  over  the  expected  life- 
cycle.  The  term  Total  Life-Cycle  Cost  of  Ownership  is  also 
referred  to  as  Total  Ownership  Cost. 

Training  -  instruction  and  applied  exercises  for  the  attainment 
and  retention  of  skills,  knowledge,  abilities,  and  attitudes 
required  to  accomplish  tasks.  (see  definition  in  MIL-HDBK-2 9612- 
4A  Glossary  for  Training) 

Unit  Cost  -  there  are  different  kinds  of  unit  cost: 

Average  Procurement  Unit  Cost  (APUC)  -  is  the  amount  equal  to 
the  total  procurement  cost  divided  by  the  total  procurement 
quantity  (Defense  Acquisition  Guidebook,  section  2 . 1 . 1  .  1  .  (  6) )  . 

The  Defense  Acquisition  Guidebook  is  currently  available  on  the 
Internet  at  https :/ / dag . dau . mil  by  individual  chapters  or  at 
Defense  Acquisition  Guidebook  (Entire  Document)  current  as  of  the 
date  published,  but  that  may  not  contain  the  most  current 
guidance . 

Procurement  Unit  Cost  (PUC)  -  with  respect  to  a  major  defense 
acquisition  program,  means  the  amount  equal  to  the  total  of  all 
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funds  programmed  to  be  available  for  obligation  for  procurement 
for  the  program,  divided  by  the  number  of  fully-configured  end 
items  to  be  procured  (10  U.S.C.  Section  2432  -  Selected 
Acquisition  Reports) . 

Program  Acquisition  Unit  Cost  (PAUC)  -  with  respect  to  a 
major  defense  acquisition  program,  means  the  amount  equal  to  the 
total  cost  for  development  and  procurement  of,  and  system- 
specific  military  construction  for,  the  acquisition  program, 
divided  by  the  number  of  fully-configured  end  items  to  be 
produced  for  the  acquisition  program  (10  U.S.C.  Section  2432  - 
Selected  Acquisition  Reports) . 

Weapons /Weapon  Systems  -  all  arms,  munitions,  materiel, 
instruments,  mechanisms,  devices,  and  those  components  required 
for  their  operation,  that  are  intended  to  have  an  effect  of 
injuring,  damaging,  destroying,  or  disabling  personnel  or 
property,  to  include  non-lethal  weapons.  For  purposes  of  the 
legal  review  required  by  SECNAVINST  5000. 2E,  weapons  do  not 
include  launch  or  delivery  platforms,  such  as,  but  not  limited 
to,  ships  or  aircraft,  but  rather  the  weapons  or  weapon  systems 
contained  on  those  platforms. 

Weapon  System  Acquisition  Program  -  an  overarching  term  that 
applies  to  a  program  for  acquisition  of  a  weapon  system  that 
includes  a  host  platform  (e.g.,  ship,  submarine,  or  aircraft), 
missile,  weapon,  munitions,  training  system,  combat  system, 
subsystem ( s ) ,  component ( s ) ,  equipment ( s ) ,  associated  software,  or 
principal  items  that  may  be  acquired  collectively  or  individually 
(i.e.,  all  acquisition  programs  other  than  information  technology 
acquisition  programs) . 
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Chapter  10 
List  of  Acronyms 


3-M 

AAP 

ACAT 

ACMC 

ACO 

ACOS 

ACT 

ACTD 

ADM 

ADM 

AIS 

AO 

AoA 

AP 

APB 

API 

ARB 

ARE 

AS 

ASN (FM&C) 

ASN (EI&E) 

ASN (M&RA) 

ASN (RD&A) 

AT 

ATC 

BIT 

BLRIP 

BUMED 

CAE 

CAI 

CAIG 

CAIV 

CAO 

CARD 

C/SSR 

C4I 

C4ISR 

CBR 

CCA 

CCDR 


Maintenance  and  Material  Management 
Abbreviated  Acquisition  Program 
Acquisition  Category 

Assistant  Commandant  of  the  Marine  Corps 

Administrative  Contracting  Officer 

Assistant  Chief  of  Staff 

Acquisition  Coordination  Team 

Advanced  Concept  Technology  Demonstration 

Acquisition  Decision  Memorandum 

Advanced  Development  Model 

Automated  Information  System 

Action  Officer 

Analysis  of  Alternatives 

Acquisition  Plan 

Acquisition  Program  Baseline 

Acquisition  Program  Integration 

Acquisition  Review  Board 

Acquisition  Reform  Executive 

Acquisition  Strategy 

Assistant  Secretary  of  the  Navy  (Financial 
Management  and  Comptroller) 

Assistant  Secretary  of  the  Navy  (Energy, 
Installations  and  Environment) 

Assistant  Secretary  of  the  Navy  (Manpower  and 
Reserve  Affairs) 

Assistant  Secretary  of  the  Navy  (Research, 
Development  and  Acquisition) 

Anti-Tamper 

Air  Traffic  Control 

Built-In  Test 

Beyond  Low-Rate  Initial  Production 
Bureau  of  Medicine 

Component  Acquisition  Executive  (i.e.,  ASN (RD&A) ) 

Critical  Application  Item 

Cost  Analysis  Improvement  Group 

Cost  as  an  Independent  Variable 

Contract  Administration  Office 

Cost  Analysis  Requirements  Description 

Cost  and  Schedule  Status  Report 

Command,  Control,  Communications,  Computers  and 
Intelligence 

Command,  Control,  Communications,  Computers, 

Intelligence,  Surveillance,  and  Reconnaissance 
Chemical,  Biological  and  Radiological 
Clinger-Cohen  Act 
Contractor  Cost  Data  Reporting 
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CCP 

CD 

CDD 

CEB 

CFFC 

CFR 

CFSR 

CG 

CHSENG 

CIAO 

CIO 

CIP 

CMC 

CNO 

CNR 

COE 

COI 

COMMARCORSYSCOM 

COMNAVSECGRU 

COMOPTEVFOR 

COTS 


CPD 

CPR 

CRD 

CSI 

DA 

DAA 

DAB 

DAES 

DAMIRS 

DASN 
DASN (AP) 

DASN (RDT&E) 


DC 

DFARS 

DIA 

DII 

DIRSSP 

DISA 

DISR 


DIACAP 

DM  I 
DoD 


Consolidated  Cryptologic  Program 
Combat  Development 
Capability  Development  Document 
Chief  of  Naval  Operations  Executive  Board 
Commander,  Fleet  Forces  Command 
Code  of  Federal  Regulations 
Contract  Funds  Status  Report 
Commanding  General 
Chief  Systems  Engineer 

Critical  Infrastructure  Assurance  Officer 
Chief  Information  Officer 
Critical  Infrastructure  Protection 
Commandant  of  the  Marine  Corps 
Chief  of  Naval  Operations 
Chief  of  Naval  Research 
Common  Operating  Environment 
Critical  Operational  Issue 
Commander,  Marine  Corps  Systems  Command 
Commander,  Naval  Security  Group 
Commander,  Operational  Test  and  Evaluation  Force 
Commercial -Of f- The -She If 
Capability  Production  Document 
Contract  Performance  Report 
Capstone  Requirements  Document 
Critical  Safety  Item 
Developing  Activity 
Designated  Approval  Authority 
Defense  Acquisition  Board 
Defense  Acquisition  Executive  Summary 
Defense  Acquisition  Management  Information  Retrieval 
System 

Deputy  Assistant  Secretary  of  the  Navy 

Deputy  Assistant  Secretary  of  the  Navy  (Acquisition 

and  Procurement) 

CHSENG  Deputy  Assistant  Secretary  of  the  Navy  (Research, 
Development,  Test  and  Evaluation)  Chief  Systems 
Engineer 

Deputy  Commandant 

Defense  Federal  Acquisition  Regulation  Supplement 
Defense  Intelligence  Agency 
Defense  Integrated  Infrastructure 
Director  Strategic  Systems  Program 
Defense  Information  Systems  Agency 
Defense  Information  Technology  Standards  Registry 
which  is  now  included  in  the  Global  Information 
Grid  Technical  Guidance  (GTG) 

DoD  Information  Assurance  Certification  and 
Accreditation  Process 
Data  Management  and  Interoperability 
Department  of  Defense 
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DON 

DOT&E 

DOTMLPF-P 


DRPM 
DRPM  SSP 

DT 

DT&E 

DTIC 

DTSE&E 

DWCF 

E3 

EA 

EAT 

EC 

ECCM 

ECM 

ECP 

EDI 

EMC 

EMD 

EMI 

EMP 

EMV 

EO 

EOA 

ESOH 

EW 

EFDS 

FAR 

FCB 

FCCC 

FCT 

FD 

FEA 

FET 

FFR 

FIBL 

FIP 

FITS 

FMC 

FMECA 

FMF 

FMP 

FOC 

FoS 

FOT&E 

FRCC 


Department  of  the  Navy 

Director,  Operational  Test  and  Evaluation 
Doctrine,  Organization,  Training,  materiel. 

Leadership  and  education.  Personnel,  Facilities, 
and  Policy 

Direct  Reporting  Program  Manager 

Direct  Reporting  Program  Manager  Strategic  Systems 
Program 

Developmental  Testing 

Developmental  Test  and  Evaluation 

Defense  Technical  Information  Center 

Director,  Test  Systems  Engineering  and  Evaluation 

Defense  Working  Capital  Fund 

Electromagnetic  Environmental  Effects 

Evolutionary  Acquisition 

External  Airlift  Transportation 

Electronic  Commerce 

Electronic  Counter-Countermeasures 

Electronic  Countermeasures 

Engineering  Change  Proposal 

Electronic  Data  Interchange 

Electromagnetic  Compatibility 

Engineering  and  Manufacturing  Development 

Electromagnetic  Interference 

Electromagnetic  Pulse 

Electromagnetic  Vulnerability 

Executive  Order 

Early  Operational  Assessment 

Environment,  Safety,  and  Occupational  Health 
Electronic  Warfare 

Expeditionary  Force  Development  System 

Federal  Acquisition  Regulation 

Functional  Capabilities  Board 

FORCEnet  Consolidated  Compliance  Checklist 

Foreign  Comparative  Testing 

Failure  Definition 

Functional  Economic  Analysis 

FORCEnet  Enterprise  Team 

Full  Fleet  Release 

FORCEnet  Implementation  Baseline 

Federal  Information  Processing 

FORCEnet  Implementation  Tool  Suite 

Full  Mission  Capable 

Failure  Modes,  Effects,  and  Criticality  Analysis 

Fleet  Marine  Forces 

Fleet  Modernization  Program 

Full  Operational  Capability 

Family  of  Systems 

Follow-on  Operational  Test  and  Evaluation 
FORCEnet  Requirements/Capabilities  and  Compliance 
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FYDP 

FYMTP 

GIDEP 

GIG 

GIG  MA 
GTG 
HERP 
HERF 

HERO 

HFE 

HMCM 

HQMC 

HSI 

IA 

IBR 

ICD 

ICE 

IER 

ILS 

IM 

IMMP 

INSURV 

IOC 

IOT&E 

IPO 

IPPD 

IPT 

IR 

IRM 

IS 

ISO 

IT 

ITD 

JCIDS 

JPD 

JROC 

JTA 

JT&E 

JUON 

KSA 

KSA 

LBTS 

LCC 

LCL 

LFT&E 

LI 

LIMSCOPE 

LMI 


Future  Years  Defense  Program 
Five-Year  Master  Test  Plan 

Government-Industry  Data  Exchange  Program 
Global  Information  Grid 
Global  Information  Grid  Mission  Area 
Global  Information  Grid  Technical  Guidance 
Hazards  of  Electromagnetic  Radiation  to  Personnel 
Hazards  of  Electromagnetic  Radiation  to  Volatile 
Materials 

Hazards  of  Electromagnetic  Radiation  to  Ordnance 

Human  Factors  Engineering 

Hazardous  Material  Control  Management 

Headquarters  Marine  Corps 

Human  Systems  Integration 

Information  Assurance 

Integrated  Baseline  Review 

Initial  Capabilities  Document 

Independent  Cost  Estimate 

Initial  Evaluation  Report 

Integrated  Logistics  Support 

Information  Management 

Interim  Manpower  Management  Policy 

(Board  of)  Inspection  and  Survey 

Initial  Operational  Capability 

Initial  Operational  Test  and  Evaluation 

International  Program  Office 

Integrated  Product  and  Process  Development 

Integrated  Product  Team 

Information  Resources 

Information  Resources  Management 

Information  Systems 

International  Organization  for  Standardization 
Information  Technology 
Integrated  Topside  Design 

Joint  Capabilities  Integration  and  Development 
System 

Joint  Potential  Designator 

Joint  Requirements  Oversight  Council 

Joint  Technical  Architecture 

Joint  Test  and  Evaluation 

Joint  Urgent  Operational  Need 

Key  System  Attributes 

Knowledge,  Skills  and  Abilities 

Land-Based  Test  Site 

Life-Cycle  Cost 

Life-Cycle  Logistics 

Live  Fire  Test  and  Evaluation 

Line  Item 

Limitation  to  Scope  of  Testing 
Logistics  Management  Information 


10-4 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


LORA 

LRIP 

LSA 

M&S 

MAIS 

MARCORSYSCOM 

MC 

MC 

MC&G 

MCCDC 

MCEB 

MCIC 

MCO 

MCOTEA 

MCP 

MCTSSA 

MDA 

MDAP 

ME 

ME 

MET CAL 

METOC 

MOA 

MOE 

MOP 

MOP 

MOU 

MPT 

MTBOMF 

NAE 

NAPS 

NATO 

NAVAIRSYSCOM 

NAVMAC 

NAVSEASYSCOM 

NCB 

NCCA 

NCDP 

NCES 

NCTS 

NDI 

NDPC 

NEPA 

NETWARCOM 

NIB 

Nil 

NIST 

NMCARS 


Level  of  Repair  Analysis 

Low-Rate  Initial  Production 

Logistics  Support  Analysis 

Modeling  and  Simulation 

Major  Automated  Information  System 

Marine  Corps  Systems  Command 

Mission  Capable 

Mission  Critical 

Mapping,  Charting  and  Geodesy 

Marine  Corps  Combat  Development  Command 

Military  Communications-Electronics  Board 

Marine  Corps  Intelligence  Center 

Marine  Corps  Order 

Marine  Corps  Operational  Test  and  Evaluation 
Activity 

Mission  Capability  Packages 

Marine  Corps  Tactical  Systems  Support  Activity 
Milestone  Decision  Authority 
Major  Defense  Acquisition  Program 
Manpower  Estimate 
Mission  Essential 
Metrology  and  Calibration 
Meteorology  and  Oceanography 
Memorandum  of  Agreement 
Measure  of  Effectiveness 
Measure  of  Performance 
Memorandum  of  Policy 
Memorandum  of  Understanding 
Manpower,  Personnel,  and  Training 
Mean  Time  Between  Operational  Mission  Failure 
Department  of  the  Navy  Component  Acquisition 
Executive 

Navy  Acquisition  Procedures  Supplement 

North  Atlantic  Treaty  Organization 

Naval  Air  Systems  Command 

Naval  Manpower  Analysis  Center 

Naval  Sea  Systems  Command 

Naval  Capabilities  Board 

Naval  Center  for  Cost  Analysis 

Naval  Capabilities  Development  Process 

Net-Centric  Enterprises  Services 

Naval  Computer  and  Telecommunications  Station 

Non-Developmental  Item 

National  Disclosure  Policy  Committee 

National  Environmental  Policy  Act 

Network  Warfare  Command 

Not-to-Interfere  Basis 

Networks  and  Information  Integration 

National  Institute  of  Standards  and  Technology 

Navy  Marine  Corps  Acquisition  Regulation  Supplement 


10-5 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


NORAD 

NOTAL 

NPOC 

NRB 

NSA 

NSS 

NTIA 

NTSP 

OA 

OA 

O&S 

OASN 

OMB 

ONR 

OPEVAL 

OPNAV 

OPREP 

OPSEC 

OPTEVFOR 

OSD 

OT 

OT&E 

OTA 

OTC 

OTD 

OTRR 

OUSD (AT&L) 

P3I 

PA&E 

PAPL 

PAT&E 

PBS 

PDM 

PDR 

PDREP 

PE 

PEO 

PESHE 

PM 

PMO 

POA&M 

POM 

PPBES 

PQDR 

PSA 

PTTI 


North  American  Air  Defense  Command 
Not  To  All 

Navy  Point  of  Contact 
Navy  Review  Board 
National  Security  Agency 
National  Security  Systems 

National  Telecommunications  and  Information 
Administration 
Navy  Training  Systems  Plan 
Open  Architecture 
Operational  Assessment 
Operating  and  Support 

Office  of  the  Assistant  Secretary  of  the  Navy 
Office  of  Management  and  Budget 
Office  of  Naval  Research 
Operational  Evaluation 

Office  of  the  Chief  of  Naval  Operations 
Operational  Report 
Operations  Security 

Operational  Test  and  Evaluation  Force 
Office  of  the  Secretary  of  Defense 
Operational  Testing 
Operational  Test  and  Evaluation 
Operational  Test  Agency 
Operational  Test  Coordinator 
Operational  Test  Director 
Operation  Test  Readiness  Review 
Office  of  the  Under  Secretary  of  Defense 
(Acquisition,  Technology  and  Logistics) 
Pre-planned  Product  Improvement 
Program  Analysis  and  Evaluation 
Preliminary  Allowance  Parts  List 
Production  Acceptance  Test  and  Evaluation 
Project  Baseline  Summary 
Program  Decision  Meeting 
Program  Deviation  Report 

Product  Deficiency  Reporting  and  Evaluation  Program 

Program  Element 

Program  Executive  Officer 

Programmatic  Environment,  Safety,  and  Occupational 
Health  Evaluation 
Program  Manager 
Program  Management  Office 
Plan  of  Action  and  Milestones 
Program  Objective  Memorandum 

Planning,  Programming,  Budgeting,  and  Execution 
System 

Product  Quality  Deficiency  Report 
Principal  Staff  Assistant 
Precise  Time  and  Time  Interval 
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QRA 

R3B 

RADHAZ 

RAM 

RCCFB 

RCCRB 

RD  &  A 

RDC 

RDDS 

RDT&E 

RFP 

RO 

ROD 

SAR 

SASCO 


S&T 

SC 

SECNAV 

SECR 

SEO 

SES 

SEW 

SI 

SIE 

SME 

SoS 

SPAWARSYSCOM 

SPS 

SPR 

SSA 

SQT 

STA 

SYSCOM 

T&E 

T&E  WIPT 

TAC 

TACP 

TD 

TECG 

TECHEVAL 

TEIN 

TEMP 

TIWG 

TLCSM 

TOC 

TPD 

TPWG 


Quick  Reaction  Assessment 

Resources  and  Requirements  Review  Board 

Radiation  Hazard 

Reliability,  Availability,  and  Maintainability 
Requirements/Capabilities  and  Compliance  Flaq  Board 
Requirements/Capabilities  and  Compliance  Review  Board 
Research,  Development  and  Acquisition 
Rapid  Deployment  Capability 

Research  and  Development  Descriptive  Summary 

Research,  Development,  Test  and  Evaluation 

Request  for  Proposal 

Requirements  Officer 

Record  of  Decision 

Selected  Acquisition  Report 

Security,  Acquisition  Systems  Protection,  Systems 
Security  Enqineering,  Counter  Intelligence,  and 
Operations  Security 
Science  and  Technology 
Scoring  Criteria 
Secretary  of  the  Navy 
Standard  Embedded  Computer  Resources 
Software  Executive  Official 
Senior  Executive  Service 
Space  and  Electronic  Warfare 
International  System  of  Units 
Standards  Improvement  Executive 
Subject  Matter  Expert 
System  of  Systems 

Space  and  Naval  Warfare  Systems  Command 
System  Performance  Specification 
Software  Problem  Reports 
Source  Selection  Authority 
Software  Qualification  Testing 
System  Threat  Assessment 
Systems  Command 
Test  and  Evaluation 

Test  and  Evaluation  Working-level  Integrated 
Product  Team 

Technical  Analysis  Center  (Farragut) 

Technology  Assessment  and  Control  Plan 
Test  Director 

Test  and  Evaluation  Coordination  Group 
Technical  Evaluation 

Test  and  Evaluation  Identification  Number 
Test  and  Evaluation  Master  Plan 
Test  Integration  Working  Group 
Total  Life  Cycle  Systems  Management 
Total  Ownership  Cost 
Test  Planning  Document 

Legacy  term:  Test  Planning  Working  Group 


10-7 


Enclosure  (1) 


SECNAV  M-5000.2 
May  2012 


TR 

TRA 

TSE&E 

TSP 

TSP 

TTSP 

UCR 

U.S.C. 

USD (AT&L) 

USJFCOM 

USMC 

USN 

USNO 

UTC 

UNP 

UON 

UUNS 

VAMOSC 

VCD 

VCNO 

VIE 

WBS 

WSA 

WSE 


Test  Report 

Technology  Readiness  Assessment 

Test,  Systems  Engineering  and  Evaluation 

Test  Support  Package 

Training  System  Plan 

Test  Threat  Support  Package 

Unit  Cost  Report 

United  States  Code 

Under  Secretary  of  Defense  (Acquisition,  Technology 
and  Logistics) 

United  States  Joint  Forces  Command 
United  States  Marine  Corps 
United  States  Navy 
United  States  Naval  Observatory 
Coordinated  Universal  Time 
Urgent  Needs  Process 
Urgent  Operational  Need 
Urgent  Universal  Need  Statement 

Visibility  and  Management  of  Operating  and  Support 
Costs 

Verification  of  Corrected  Deficiencies 
Vice  Chief  of  Naval  Operations 
Visual  Information  Equipment 
Work  Breakdown  Structure 
Warfare  Systems  Architect 
Warfare  Systems  Engineer 
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